Cowork & Dispatch

There are now four rungs between "Claude answers me" and "Claude works while I sleep". Most people stop on rung one. This guide is rungs two and three.

Each rung trades a little control for a lot of throughput. The skill of this whole guide is choosing the rung deliberately, per job, instead of doing everything at the rung you happen to be comfortable on.

Cowork is the desktop app's agentic mode: Claude plans a multi-step task, then executes it against your real files and apps, producing real deliverables rather than chat text.

• Real files. It reads and writes inside folders you've granted: renaming, reorganising, extracting, assembling.
• Real deliverables. Finished spreadsheets, documents and slide decks land in your folder, not in a side panel.
• Your apps too. Connectors give it Gmail, Drive, Slack, Calendar and whatever else you've linked, so "cross-reference the invoices folder against what's actually been paid" is one instruction.
• Your standards. It uses the same Skills and Plugins as the rest of Claude, plus its own instruction layers (section 03).

The mental shift from chat is the same one as Claude Code's: describe the outcome, not the steps. "Every contract in this folder, renamed to date-client-type, with a summary index spreadsheet" is a complete Cowork brief.

Fifteen minutes of deliberate setup separates "wow" from "why is it asking me things constantly".

1. Grant working folders, exclude sensitive ones. Give it the folders where work happens; keep finance records, personal documents and anything regulated out of scope entirely. Scope is your first safety layer, and the one that never fails.
2. Write global instructions: the rules true of everything you do. Naming conventions, "never delete, archive instead", British English, where finished work goes.
3. Write folder-level instructions for each working folder: what lives here, what outputs look like, this folder's quirks. Same layering rule as guide 03: narrowest layer that's true.
4. Run one supervised job end to end. Watch the plan, watch the approvals, correct it out loud. You're calibrating each other.

This folder holds client deliverables in progress.

- Finished work goes to /out, named
  YYYY-MM-DD - Client - Description.
- Never delete or overwrite; superseded versions move
  to /archive.
- Drafts are .docx unless the brief says otherwise.
- If a task needs a file that isn't here, stop and ask;
  don't search other folders.

By default Cowork works through files and connectors. Computer use is the extra, off-by-default mode where Claude sees your screen and drives apps and the browser like a person would.

• You don't need it for most work. File and connector jobs, the bulk of Cowork's value, run without it.
• Turn it on for the last mile: the legacy system with no export button, the web form that must be filled in, the app nothing else can reach.
• Treat it as the highest-trust mode. Screen-and-mouse access is broad by nature. Enable it for the task, watch the first runs, and turn it off after.

Cowork has its own Projects, and they are not the claude.ai kind. Knowing the differences saves real confusion.

The import is the practical bridge: brief and context built up in chat-land (guide 03) becomes the starting knowledge for desk-land execution.

Dispatch is the control tower. You send one high-level instruction, from your desktop or your phone, and it breaks the work into tasks, runs each as its own Cowork or Claude Code session on your machine, and reports back.

• From anywhere. The signature move is sending work from your phone at 8am and arriving to finished output. The work still happens on your desktop, using its files, connectors and Skills.
• One long-running thread. Dispatch is a single persistent conversation that accumulates your working context; the parallelism happens in the child tasks it spawns, not in multiple Dispatch threads.
• Every child is inspectable. Open any task to read its full transcript, send follow-ups, or spin further work off its result.
• Availability. macOS and Windows, Pro and Max plans, research preview: expect it to evolve under you.

This is the technique the whole guide exists for: one instruction that becomes many parallel workers, each with its own context and file access, none of them polluting the others.

The pattern: name the unit of work, tell Dispatch to run one task per unit, and define what each task must produce. Six prospects, one research brief each. Twelve folders, one tidy-and-index job each. Five drafts, one review each.

In /work/prospects there's a file called shortlist.csv
with 6 companies. Run a separate task for each company:

- Research them (use the connectors and the web) and
  write a one-page brief: what they do, recent news,
  likely pain points, who we should approach.
- Save each as /work/prospects/out/[Company] - brief.docx
  using our house template in /work/templates.

Each task stands alone; don't share findings between
them. When all six are done, write a summary task:
rank the six by fit and tell me which two to call
first, and why.

Why "each task stands alone" matters

Each child gets a clean context. That's a feature: research on company three can't contaminate company five, and one child hitting a dead end doesn't stall the rest. Design your units so they're genuinely independent, and put anything they all need (templates, criteria, house rules) in files and folder instructions rather than in the moment's phrasing.

And it stacks: a child task running Claude Code can spawn its own subagents (guide 07, section 10). Dispatch fans out across jobs; each job can fan out across specialists. That's a lot of Claude from one sentence on a phone.

Dispatch has a few hard behaviours. Work with them and it purrs; fight them and you'll think it's broken.

• Dependent chains need you as the relay. "Research the market, then write the deck from the research" doesn't work as one instruction yet; task B can't consume task A's output automatically. Send A, review, then send B pointing at A's output file. Your review in the middle is usually worth having anyway.
• Follow up inside the child. A task that's 90% right gets its correction in that task's transcript, where all its context lives, not as a fresh top-level instruction.
• One thread, so keep it legible. Everything accumulates in a single conversation. Batch related work under clear instructions ("Monday morning batch: three tasks…") so the thread reads like a log, not a junk drawer.
• Build on results explicitly. "Take the ranking from the summary task and draft outreach emails for the top two" works because you named the source.

The failure modes of remote-controlling your own desktop are mundane, and all preventable.

• The machine must stay awake with the app open. Asleep laptop, paused tasks. If you're sending work from your phone, check the lid's open and power settings won't betray you.
• Permissions time out. A child task that needs an approval waits about ten minutes; no answer and it's auto-denied, and the task carries on without that action. Result: a "finished" job with a quiet hole in it.
• Pre-authorise the routine. Most permission prompts are predictable: folder access, connector use. Grant the standing ones in settings and in your instructions so children don't stall on the obvious.
• No completion pings. Dispatch doesn't notify you when work finishes; checking the thread is on you. Pair fire-and-forget with a check-back habit: send the batch, set a timer, review in one sitting.
• Read the report, then spot-check one deliverable. Agents summarise their own work charitably, like everyone else. Open one output file per batch and look.

The pieces of this series compose into one system. Here's the assembled machine.

1. Chat + Projects (03) hold the thinking: briefs, decisions, context. Import into Cowork when it's time to execute.
2. Skills (05) encode your standards once: house style, templates, checklists. Every Cowork and Code session, including every Dispatch child, applies them automatically.
3. Cowork executes on your files; Claude Code (07) takes the jobs needing precision, code or bulk mechanics. Dispatch happily manages both kinds of children.
4. Dispatch is the throughput layer: batches from your phone, parallel where the work allows.
5. Routines own the calendar: the jobs that recur, on infrastructure that doesn't sleep.

A realistic week: Monday 8am, three fan-outs from the phone. Review at 10 with coffee, two follow-ups sent into child tasks, one output promoted to the client project's knowledge base. The recurring Friday report? That stopped being your job the week you made it a Routine.

The distilled version.

1. Pick the rung per job. Supervision for the new and risky; Dispatch for the proven and repetitive.
2. Scope is safety. Grant working folders, exclude sensitive ones, "archive, never delete" in global instructions.
3. First time supervised, tenth time dispatched. Never fan out a job type you haven't watched succeed once.
4. Design independent units. Shared needs go in files and folder instructions, not in the prompt.
5. You are the relay between dependent tasks. A, review, B. The review earns its place.
6. Corrections go into the child, batches go into the thread, durable outputs get promoted to a project.
7. Machine awake, permissions pre-granted, timer set. The three-item pre-flight for every phone-sent batch.
8. Spot-check one deliverable per batch. Trust the report the way you'd trust any keen new hire's self-review.