You designed the workflow in the last lesson. You did the reasoning work — the framework and the audience research. Now it's time to orchestrate the production. Three Claude surfaces will be working together to ship the project. Claude Design handles the visual work, Claude Code builds the production page and the small automation, and Cowork runs the recurring email sequence. Chat threads through all of it for the reasoning that keeps the work coherent. By the end of this lesson, the whole stack is in motion. Let's get started!

Orchestration is the skill of moving work across multiple surfaces so the outputs integrate. Each tool you've learned can produce strong work on its own.

But put them in sequence, and the question isn't whether each one works — it's whether what they produce fits together.

A workflow can be well-designed and still produce an incoherent deliverable. Each stage on its own can produce a decent result, but the assembly may not work at the handoffs. Orchestration is the work of catching these integration failures.

You ended last lesson with two outputs in hand: the framework outline (developed in chat with Thinking + Research), and the audience research bundle (produced by Cowork). Three deliverables remain:

You'll move through them in the following order:

The first execution moment is the handoff from chat to Claude Design. The framework outline you developed lives as text — a structured document with the central argument, the three case studies, and the sequence. The deck has to carry that structure into a visual deliverable. The risk: Claude Design generates a beautiful deck that misses the framework's actual logic.

You can prevent the risk by using the prompt you write when starting the Claude Design project. The prompt has to do two things: name the framework structure explicitly, and tell Claude Design that the structure is non-negotiable while the visual register is more open.

With the deck rendered, the next handoff is to the companion page. The deck and the page have to feel like the same thing. You don't build the deck, then start a new Claude Design project for the page, trying to match the visual identity by description. Instead, you set up a design system in Claude Design that the deck and the page both reference. The design system is the carrier of the visual identity — typography, color tokens, spacing rules, and the components that both projects use.

Setup happens in Claude Design. Go to the main page and click Set up design system. Upload the deck you just built as the source material, Claude analyzes the deck and generates the design system. You have a typography, color palette (primary, secondary, accent), components, and layout patterns.

You review what Claude generated, validate it with a quick test prompt to make sure the extracted system matches the deck's feel, then toggle "Published" on. From that point, any new project you create in Claude Design uses this design system by default.

You walk through the page side by side with the deck and notice something off. The deck's accent color appears on the page, but it's slightly different — a touch warmer, less saturated. Typography and spacing match, but the accent color is not quite the same. This is an integration failure, and now you'll fix it.

For any execution-time failure, the analysis structure stays the same:

The accent color drift fits the structure cleanly:

Once the page looks right in Claude Design, the production handoff to Claude Code happens. This is the handoff you learned before — one instruction packages the approved prototype, the design intent, and the constraints into a bundle that Claude Code picks up. Quality check at handoff: the production page visually matches the approved prototype on desktop and mobile.

Claude Code picks up the handoff bundle and generates the production code — HTML, CSS, the opt-in form's backend, and deployment scaffolding. Same pattern you learned before: you test that the page renders correctly on desktop and mobile and deploy when it matches the approved prototype.

With the code reviewed and the page rendering correctly, you publish. As you want the website to be live, you need a host — a service that stores your website and makes it available online. The most common free hosts for this kind of page are Netlify, Vercel, and GitHub Pages. All of them have free tiers that cover a 200-person event with no friction. Go to the host website and publish your project online there.

With the deck and the page shipped, the remaining deliverables are the article version and the follow-up email sequence. The article goes back into chat. You take the framework outline, the case studies, and the deck's specific examples, and ask Claude to draft a long-form version of the talk.

Step back and look at what's in place. The framework is settled. The audience research is done. The slide deck is ready. The companion page is live and visually coherent with the deck. And now the article exists in long-form for the readers who'll find your work after the talk. One last thing — the email sequence — is the piece that turns one-time visitors into a relationship that continues past the talk. Let's work on that one!

With the page live and opt-ins coming in, the email sequence has to run. Three emails per opt-in:

Day 7 and Day 14 are straightforward — Cowork can send them on schedule from a template. The Day 0 welcome is harder. Each one needs personalization that references the visitor's specific opt-in path. The orchestration move: have Claude Code generate the personalized welcome drafts, and have Cowork send them along with the templated follow-ups.

The two layers split the work:

The handoff between layers is the shared folder. Claude Code writes; Cowork reads and sends. Each layer does what it's best at — Claude Code at producing one-off personalized work, Cowork at sending on a schedule.

The Claude Code tool now does the hardest part of the email sequence — writing personalized welcomes grounded in the framework. Every time it runs, fresh drafts land in output/welcomes/, one per opt-in, named by visitor email so they can be matched back later. But drafts in a folder have to be sent at the right moment, to the right person. That's the orchestration job for Cowork. Cowork will watch for new opt-ins, pick up the Day 0 welcome from the folder Claude Code writes to, send it, then queue the Day 7 and Day 14 follow-ups for the right dates. The draft generation and the sending stay separate — Claude Code produces, Cowork sends. Each tool does what it's best at.

Both layers built. You test the system against a sample batch of five opt-ins from your CSV. The system is ready. Each week, the Claude Code drafter runs against the new opt-ins. Cowork reads what it wrote and sends Day 0 immediately; Day 7 and Day 14 follow on schedule. You don't touch the emails after the initial test — the system handles itself. What was an hour of weekly manual personalization is now a system that runs without you.

The talk's three weeks out. The whole workflow happened in Claude: reasoning in chat, visual work in Claude Design, production handoff in Claude Code, and recurring work in Cowork. Each layer did what it was best at; the orchestration focused on ensuring the outputs integrated.

You've now executed a full multi-layer workflow end-to-end. You've seen what handoffs look like in practice, where integration failures live, how to recover from them, and where automation earns its place. The next lesson moves from one project to a recurring system. You'll see how the same orchestration skill applies to running a small business or a team with Claude as the operating layer — not for a one-time event like a talk, but for ongoing work that compounds week over week. Let's keep going!