The bridge between defining your project and building it.
Last week you selected a project, defined the scope, and delegated responsibilities. Some groups left with a clear plan. Some left with a direction that still needs sharpening. Both are normal. The point of this session is to cross the line from planning into building, even if the first build step is small.
By the end of today, every group should have taken at least one concrete step: a working draft, a first integration, an architecture mapped in Claude, or a research assignment completed and shared back. Something tangible that did not exist before today.
The point is not what you build. It is learning how to build. The group project produces a foundation you can take with you and adapt to your own systems, your own workflows, your own problems. If you leave this program knowing how to scope, build, and iterate on an AI-powered system, the specific project you built along the way is just the first of many.
Module 7 was Define, Design, and Delegate. Module 9 will be Build and Review: hands-on construction with the clock running toward capstone. This session is the bridge. It has two jobs.
First, sharpen. If your project scope is still soft, this is the session to harden it. Confirm what the demo will show. Confirm who owns what. Confirm what "done" looks like for capstone. If you cannot describe the demo in two sentences, the scope is not sharp enough yet.
Second, start. Take the first build step as a group. Not the whole thing. One piece. Connect one data source. Draft one set of assessment questions. Map one architecture. Produce one working output. The goal is to leave this session with something you can point to and say: that did not exist an hour ago.
Build one feature that works. Confirm it works. Then add the next one. The practitioners who build agents for a living have learned this the hard way: most failed builds attempt too many things at once. One context layer at a time. One integration at a time. One working piece before the next.
Think about it like onboarding a new executive assistant. You do not hand them your passwords on day one. You delegate something small. You see how they do. You expand the role. Your AI system deserves the same discipline.
There are no bonus points for running early. A clean crawl that you can demonstrate is more impressive at capstone than an ambitious sprint that crashes.
Claude will recommend a path. It will give you step-by-step instructions. It will tell you the path is straightforward and easy. Sometimes it is. Often it is not. Before you commit to an integration, a data source, or an architecture decision, ask Claude to challenge its own recommendation. What alternatives did you consider? What are the cost implications? What happens when we exceed the free tier? What are we not thinking about?
This is the critic protocol applied to technical decisions. The same discipline you use when reviewing a colleague's proposal applies when Claude proposes a build approach.
Your capstone presentation is eight to ten minutes. Not a pitch deck. Not a competition. A demonstration: here is what we wanted to build, here is how we approached it, here is what it does. The audience is your fellow participants from the other cohorts. They want to see what you learned and what you made, not a polished sales performance.
Work backward from that. What is the one feature that, if it works live, makes the audience say "I want that"? Identify that feature today. Build toward it in Module 9.
A simple, working demo that you can explain clearly is more impressive than an ambitious concept that breaks under pressure. Build the boat. Take it on the pond. Save the ocean for later.
This is a working session. The facilitator is here to answer questions, flag scope risks, and keep the group moving. The group owns the time.
Where does the project stand? Can you describe the capstone demo in two sentences? If yes, confirm it with the group and move on. If not, spend this time getting there. Resolve any open questions from Module 7: what is the target user, what does the system do, what does the demo show?
As a group, agree on the one thing that needs to work for the capstone demo to land. Not the whole system. The one feature that makes the audience lean forward. Everything else is context for that moment. Name it. Write it down. That is your build target for the next two weeks.
Hands on keyboards. Work in Claude Teams or individually, but stay in the room together. The goal is not to finish. The goal is to start. Connect the first data source. Draft the first set of questions. Map the architecture. Produce a first output. If you are stuck, say so. The group is your resource this week. If Claude recommends a path, use the critic protocol before committing.
What did you produce today? What needs to happen before Module 9? Who owns what? Be specific. "I will work on the integration" is not an assignment. "I will connect Google Calendar through Make.com and test it with my personal calendar by Thursday" is an assignment. Set a mid-week checkpoint if your group needs one.
Building together does not mean everyone writes code. It does not mean everyone touches Claude at the same time. It means the group owns the outcome collectively, even if different people own different pieces.
Some groups have a builder who does the technical work, a framer who shapes the narrative, a tester who breaks things on purpose, and a presenter who tells the story. Other groups have a documented process that each person follows independently, producing their own version and then comparing results. Both models work. The question is not which model is correct. The question is: can every person in the group explain what was built, why it was built that way, and what they personally learned?
If one person built it and four people watched, that is a demonstration, not a group project. If one person built it and four people can explain the decisions, the trade-offs, and what they would change, that is a group project, even if only one person touched the keyboard.
Module 9 is Build and Review. That session is fully dedicated to construction and iteration. Come to Module 9 with something to iterate on, not something to start. The bridge you cross today determines whether Module 9 is productive building time or a scramble to catch up.
Module 10 is the combined capstone with all three cohorts. Ninety minutes. Eight to ten minutes per group for the demo, plus Q&A. Plan for eight minutes of content. It will expand to twelve on its own. Lead with the working thing. Let the audience see the output before you explain the architecture. End with one sentence about where you would take it next.
Experienced presenters in the program have offered this guidance: attention is a privilege that must be earned. If your demo is tight and compelling, the Q&A will take care of itself. If you try to cover everything, you will lose people quickly. Let them smell the steak before you tell them how you cooked it.
When this program ends, the group project stays behind. But the process you used to build it does not. You now know how to define a problem in terms Claude can help solve. You know how to scope to what is buildable in a compressed timeline. You know how to divide work across people with different skill levels. You know how to critique Claude's recommendations before committing to them.
That is the foundation. The next system you build will be easier because you did this one first. And the one after that will be easier still.
Build the boat. Take it on the pond. The ocean is waiting.