Building a scheduled pipeline in Cowork.

Orchestration by convention, not by supervisor CORE

Lesson 8.3’s Claude Code pipeline had a live supervisor — the parent session. The parent read the blueprint, dispatched subagents, verified outputs, and stopped on failure. That supervisor existed, in process, the entire time the pipeline was running. You could interrupt it. You could watch it.

Cowork’s scheduled-task pipeline has no such process. There is no single program sitting above the pipeline reading the blueprint and dispatching. Instead, there is a set of scheduled tasks — independent jobs, each with its own schedule, each invoking its own skill, each writing to and reading from agreed-upon folders. The orchestration is not a thing that runs; it is a thing you arranged at authoring time, by choosing the schedules and the folder convention.

This sounds weaker than the Claude Code model, and in some ways it is. There is no live verification between stages; if the research task produces garbage at 6:00 a.m., the summarizer task at 6:10 a.m. will happily consume the garbage and produce garbage-shaped output. Nothing will stop it, because nothing is watching. This is the trade you make for the Cowork path.

In exchange, you get three things that matter for certain kinds of pipelines:

• The pipeline runs without you. The Claude Code parent session requires you to be there, typing the invocation. The Cowork pipeline fires whenever its schedule fires, whether or not you are at the machine. This is the whole point of a cadence-driven pipeline — you are reading its output at breakfast, not running it at breakfast.
• Each stage is legible on its own. Each scheduled task has its own run log, its own input folder, its own output folder. You can read the state of the pipeline by opening folders; you do not need a parent-session transcript to reconstruct what happened. The tradeoff is that between-stage verification has to live somewhere other than a running supervisor — typically as the first step of each downstream task’s skill.
• Failures are recoverable by folder. If the 6:00 a.m. research task produced bad output, you can fix the research skill, drop a corrected sources.md into the folder, and let the 6:10 a.m. summarizer task fire normally. The pipeline does not need to be re-orchestrated top-down; each stage is independent enough to be re-run on its own.

The choice between the two paths is not “which is better.” It is “which shape fits the goal.” An on-demand research brief wants a parent session. A daily briefing that lands in your inbox folder at 6 a.m. wants chained scheduled tasks. Lesson 8.4 is asking you to build the same blueprint on the Cowork path so that you have both in your hands when you pick in Part 4.

What replaces the supervisor: verification in each task CORE

A Cowork pipeline still needs verification between stages, or it will quietly corrupt downstream output the way Content Block 1 described. The verification has to live somewhere. Without a parent session, the natural place is the first step of each downstream task’s skill.

A scheduled task that has been authored to check its own upstream input begins its work with something like:

1. Read the previous stage’s output file at the expected path.
2. Check each success criterion from the handoff contract (file exists, required sections present, length band satisfied, etc.).
3. If any criterion fails, write a status file to 00-status/<stage>-skipped.md explaining which criterion failed, and exit without doing the stage’s real work.
4. Otherwise, proceed with the stage’s real work.

This pattern — self-verifying stages — is the Cowork equivalent of the parent session’s “check before dispatch” step. It lives in the skill, not in an orchestrator. Because it lives in the skill, you write it once per stage, not once per pipeline: if the same skill is used across five different scheduled pipelines, its self-verification travels with it.

A pipeline built this way has two failure-visibility helpers:

• The 00-status/ folder is the ground truth of what ran. Each task writes a status file: <stage>-completed.md, <stage>-skipped.md, or <stage>-failed.md. A glance at 00-status/ tells you whether the pipeline ran cleanly today without opening any of the intermediate files.
• A summary task (optional but recommended) runs last and consolidates. A final scheduled task, thirty seconds of work, reads every status file and writes 00-status/pipeline-<date>.md summarizing which stages completed, which skipped, which failed. It is the Cowork equivalent of the parent session’s pipeline-complete.md.

You will build the self-verification into your skills in Part 1 of the activity. The pattern is short, repetitive, and essential. Do not skip it — without it, the Cowork path is measurably weaker than the Claude Code path, in exactly the way Content Block 1 warned.

Step 1 — Define the shared folder convention

Before creating any scheduled task, decide on the pipeline name and the stage folders. For the daily briefing:

/pipeline/daily-briefing/<YYYY-MM-DD>/00-status/
/pipeline/daily-briefing/<YYYY-MM-DD>/01-research/
/pipeline/daily-briefing/<YYYY-MM-DD>/02-summary/

The date-folder is created by each stage if it does not already exist (each skill does mkdir -p on its own output folder as its first action). This is what lets the three tasks coordinate without a live supervisor — they all know the naming rule.

Step 2 — Create Task A (morning-research)

Using the create_scheduled_task tool (canonical flow in the Recipe Book), schedule morning-research to fire daily at 6:00 a.m. The task prompt is short and points at your Module 7 research plugin skill:

Invoke the <your-plugin>:research-sweep skill with:
- Topic: <your standing topics list>
- Output path: /pipeline/daily-briefing/<today>/01-research/sources.md

The skill's output contract is the Module 8
research → summary handoff contract in the
pipeline blueprint.

On completion, write
/pipeline/daily-briefing/<today>/00-status/research-completed.md
with the timestamp and source count.

On failure, write
/pipeline/daily-briefing/<today>/00-status/research-failed.md
with the failure reason.

Where <today> is resolved at runtime by the task’s date-substitution (the Recipe Book covers the exact syntax — typically {{today}} or an equivalent placeholder).

Step 3 — Create Task B (morning-summarize)

Scheduled for 6:08 a.m. — eight minutes after Task A, to leave comfortable room for Task A to finish. The task prompt has the self-verification block on top:

Read /pipeline/daily-briefing/<today>/01-research/sources.md.

First, verify the file exists and matches the
research → summary handoff contract:
- File exists.
- ## Summary section is 100–300 words.
- ## Key sources has ≥ 3 bullets each with a URL.

If any check fails, write
/pipeline/daily-briefing/<today>/00-status/summary-skipped.md
explaining which check failed. Stop.

Otherwise, invoke <your-plugin>:summarize skill with:
- Input path:  /pipeline/daily-briefing/<today>/01-research/sources.md
- Output path: /pipeline/daily-briefing/<today>/02-summary/summary.md

On completion, write
/pipeline/daily-briefing/<today>/00-status/summary-completed.md.
On failure, write summary-failed.md with the reason.

Notice the self-verification block — this is the Content Block 2 pattern, in the task prompt rather than in a parent session. The task will run whether or not Task A succeeded; it is the self-verification that keeps a failed Task A from silently corrupting the rest of the pipeline.

Step 4 — Create Task C (morning-briefing)

Scheduled for 6:15 a.m. Same self-verification pattern as Task B, reading both prior stages, producing the final briefing. Writes the consolidated pipeline-<date>.md to 00-status/.

Step 5 — First invocation

Rather than waiting for 6:00 a.m. tomorrow, use the run now option on Task A (the list_scheduled_tasks and update_scheduled_task tools expose a manual-fire mechanism; the exact button name is in the Recipe Book). Watch the /pipeline/daily-briefing/<today>/ folder populate. Then fire Task B manually; then Task C. You are simulating the timed sequence as a single burst, which is enough for the first invocation’s trace.

Step 6 — Save the trace

Save each task’s run log (Cowork exposes these through the scheduled-tasks UI) to /capstone/pipeline-v1-draft/traces/cowork/2026-04-XX-invocation-1/. Also copy the entire /pipeline/daily-briefing/<today>/ folder into the same traces folder. The Cowork trace format is slightly different from the Claude Code one — it is three run logs plus the folder snapshot rather than one parent transcript plus a folder snapshot — but the completeness target is the same: anyone reading the trace in three months can reconstruct what happened.

Picking the frozen path CORE

At this point you have two working (or partially working) pipelines implementing the same blueprint. The Module 8 capstone requires one frozen pipeline. Pick by the goal’s shape, not by which path felt easier.

The two simple rules:

• On-demand, goal-bounded pipelines live on Claude Code. You invoke the parent session when you want the output. The pipeline produces one artifact per invocation. You run it maybe twice a week. Examples: drafting a paper, producing a research brief for a project, reviewing a pull request.
• Scheduled, cadence-driven pipelines live on Cowork. The pipeline fires on a timer. You read the output at a regular time. It runs whether or not you are at the machine. Examples: a daily briefing, a weekly status digest, a morning inbox summary, a monitoring alert.

If your goal is ambiguous — it could be run on demand or on a schedule — default to Claude Code. The live supervisor makes debugging easier, and debugging is where most of your Module 8 time will go. You can always promote a working Claude Code pipeline to a scheduled one later, once its behavior is predictable. Promoting the other direction (fixing a schedule-only pipeline you cannot watch run) is harder.

Once picked:

• Move the picked path’s files to /capstone/pipeline-v1/. This includes: subagent folders or scheduled-task definitions, any skills the pipeline relies on, the blueprint (now dropping its -draft suffix), the traces folder, and the before/after block.
• Leave the other path’s files where they are, under /capstone/pipeline-v1-draft/. Rename the folder for clarity — for example, /capstone/pipeline-v1-draft/claude-code-sibling/ or /capstone/pipeline-v1-draft/cowork-sibling/. The sibling is not part of the frozen capstone but is preserved as learning evidence.
• Update /capstone/pipeline-v1/blueprint.md with a single new line at the top of the Next review section: the date 90 days from today. The budget and kill-switch placeholders stay empty for now — Lesson 8.5 fills them.

Walkthrough: the daily briefing pipeline RECIPE

Adapt the walkthrough to your own pipeline RECIPE

The reference pipeline is research → summarize → briefing on a daily cadence. Adapt as follows:

• Substitute your stages. If your goal is weekly not daily, use <YYYY-WW> folders instead of <YYYY-MM-DD>. If your goal has two stages not three, you have one fewer scheduled task (and one fewer handoff contract from Lesson 8.2 to enforce). If your goal has different stages entirely — triage → reply-draft, monitor → alert, collect → categorize → archive — substitute stage names and reorder as needed. The folder convention and self-verification pattern stay the same.
• Substitute your skills. Each scheduled task invokes one Module 7 plugin skill. If you do not have a skill that does a stage’s work, the fix belongs in Module 7, not here — either author a new skill per Module 7 Lesson 7.3, or find an off-the-shelf skill per Lesson 7.2. Do not paper over a missing skill with a long ad-hoc task prompt; that is how skill pile-up starts. Tight scheduled tasks invoke tight skills.
• Substitute your stagger intervals. The reference pipeline leaves 8 minutes between Task A and Task B, and 7 minutes between Task B and Task C. For a small daily briefing, this is plenty. For a pipeline where Task A is a heavy research sweep that might take 15 minutes, bump the stagger to 20 minutes. The stagger needs to be comfortably longer than the worst-case runtime of the upstream task, not exactly as long. A stagger that is too short will sometimes cause Task B to read a half-written sources.md; a stagger that is too long is harmless. When in doubt, stagger generously.
• Substitute your topic / input. The first invocation should run against real input (a real set of topics you actually want briefings on, real triage criteria, a real calendar window). Test topics produce test-shaped traces that teach you nothing about whether the pipeline is useful.

Run the manual invocation, save the trace, then let it run on schedule for one actual cadence before Part 3 of the activity. This matters — the second invocation should be a real scheduled run, not another manual fire, so the trace shows what actually happens when you are not at the machine.

Two-round tightening on the Cowork path RECIPE

The two-round tightening loop from Lesson 8.3 applies on this path too, with three Cowork-specific notes.

Round 1 — Read the trace, find the weakest handoff. The Cowork trace is three run logs plus the folder snapshot. Read the run logs in order; when something looks off, go to the folder snapshot and read the actual file. The weakest handoff is almost always the one where the intermediate file has a shape the downstream skill was not prepared for. Tighten the handoff contract and the upstream skill’s output section to match.

Cowork-specific note 1 — Skills, not agents. On the Claude Code path, the “round 1” target was the upstream subagent’s system prompt. On the Cowork path, the target is the upstream skill (the Module 7 plugin skill the task invokes). If the fix is small (clarify the output section), update the skill directly and bump its changelog. If the fix is large (the skill needs new capability), it may be a skill-authoring issue that belongs back in Module 7 — the skill is the reusable unit, and tightening it benefits every pipeline that uses it, not just this one.

Cowork-specific note 2 — Self-verification is your main diagnostic. On the Claude Code path, failures showed up as the parent session stopping. On the Cowork path, failures show up as <stage>-skipped.md or <stage>-failed.md files in the status folder. If your status folder shows skipped stages every day and you did not expect them to skip, the upstream skill’s output is failing the handoff contract. This is usually the first place to look.

Cowork-specific note 3 — Staggers are part of tightening. If Task B is skipping because Task A is still running at 6:08 a.m., the fix might not be in any contract or skill — it might be that your 8-minute stagger is too short. Bump it to 15 minutes. Save yourself an afternoon of contract-tuning for a problem that was timing all along. This failure mode is unique to the Cowork path; the Claude Code parent session does not have timing in the same sense.

Capture invocation 2’s trace under /capstone/pipeline-v1-draft/traces/cowork/2026-04-XX-invocation-2/. Write the before/after block in the same traces folder. Same five-element completeness as Lesson 8.3.