Cowork and
scheduled work
Everything so far has mostly been a conversation: you ask, it answers, you steer, back and forth. Cowork is a different posture. Instead of chatting your way through a job, you describe the whole outcome, point Claude at your real files and tools, and let it plan, work through the steps, and hand you back a finished thing. You stop talking through the work and start delegating it.
This matters because a lot of what fills your week is not a question, it is a job: read these five documents and compare them, pull this month's numbers into a brief, work through a folder and produce a summary. In a chat you would stitch those steps together yourself. Cowork sustains the whole arc, across several tools, and returns the deliverable. It runs on the same engine as Claude Code, so everything you just learned about oversight and control carries straight over.
You now have three ways to work with Claude, and picking the right one is most of the skill. They are not competitors; they are for different shapes of work.
The clean test is what you want at the end. If what you want is an answer you will read and act on, that is Chat, even if it had to pull from your connected tools to get there. If what you want is a thing produced and saved somewhere, a document, a deck, a spreadsheet, a folder of tidied files, that is Cowork. A connector being involved is not the signal. A deliverable is.
A good Cowork task looks a lot like the delegation you learned in the beginner course and sharpened with subagents. It names three things clearly, and when it does, the result comes back close to what you wanted instead of a confident miss.
Deliverable, inputs, nuance. That is the shape. Notice it is the same brief-it-well discipline from delegation, just aimed at a whole job instead of a single reply. A task that says "look at my vendor documents and compare them" is thin. One that says "read the five vendor PDFs in this folder, compare them on price and support terms, and give me a spreadsheet I can decide from, ignoring the marketing fluff" names all three, and comes back usable.
Handing over a whole job sounds like giving up control. Done right it is the opposite, because the surface is built to keep you in the loop at exactly the moments that matter. It shows you its plan before it starts, so you steer on paper, cheaply, the way you learned with delegation. And by default it asks before it does anything with real consequences: sending something, sharing something, deleting something.
This connects straight back to the working-safely instinct that runs through this whole course. Give it a dedicated working folder rather than turning it loose on everything. Keep a backup of anything irreplaceable before it touches it. Be precise about destructive verbs, because "clean up this folder" can mean tidy or can mean delete, and only you know which. Speed is good, but stopping to think beats speed when the action cannot be undone. The tool keeps you in control; these habits are how you use that control well.
The last piece turns a delegated job into a standing one: work that runs on a schedule, without you starting it each time. This is the loop idea from earlier, made real on your actual files and tools. A morning briefing assembled before you wake. A weekly summary produced every Friday. The job you set once and then simply receive, done.
The same rules apply, only more so, because now it runs when you are not watching. Lock the goal precisely, since you will not be there to catch drift mid-run. Keep its tools to what the job needs. And start any scheduled job that can do something consequential on a short leash, reviewing its output for the first several runs, before you trust it to run clean. A scheduled job that only reads and produces a draft is safe to let loose early. One that sends or changes things earns that freedom slowly.
Which of these surfaces and scheduled features are on your plan changes over time, so this chapter names no specific tiers. We assume you have a paid plan or an equivalent tool. Check the official plan page for what is available to you today, and treat scheduled work as a capability to grow into rather than a box to tick on day one.
Pick one real multi-step job from your week that ends in a deliverable, the kind you would normally do by hand across a few tools. Brief it as a Cowork task using deliverable, inputs, nuance. Review its plan before it runs. Let it produce the real thing. Then ask yourself: if this is a job I do on a rhythm, what would it take to schedule it safely, and where on the leash would it start?
Show the worked solution
- Cowork is for delegating whole jobs: point it at real files and tools, describe the outcome, and it plans, executes, and delivers a finished artifact.
- Choose by what you want at the end: Chat for an answer to think about, Cowork for a produced-and-saved deliverable, Code for work inside a codebase.
- A good Cowork task names three things: the deliverable, the inputs, and the nuance only you have. It is the delegation discipline aimed at a whole job.
- You stay in control: it shows a plan before it starts and asks before consequential actions. Pair that with a working folder, backups, and precise verbs.
- Scheduled work turns a delegated job into a standing one. Lock the goal, limit the tools, and start any consequential scheduled job on a short leash.
Hand one real multi-step job to Cowork this week and get back a finished deliverable, then decide whether it is worth scheduling. That closes Part Four: you can connect, build, and delegate whole jobs. Next we step up to production scale, starting with the unglamorous thing that decides whether any of this survives real volume: plans, limits, and cost.
Chat taught you to think with Claude. Cowork teaches you to hand it the work and get the thing back done. The leap is not technical, it is a change of posture: from asking about the job to trusting it with the job, on the tasks where you have briefed it well enough to earn that trust.