👇 After this module

Your system can hold a second person safely, and it can run a Monday morning without you. You have a scoped helper, access that matches trust, a keeper for the human details, and a handover you have actually tested.

The scoped second seat 🪑

Bringing someone in to help does not mean handing them everything. Your system is made of files, and you can give a helper their own corner of it: a folder with its own instructions that shows them what they need for their work and keeps the rest of your business private. This is the second seat, and it is scoped on purpose.

The whole trick is that you decide, once, what this second person can see and do. Everything else stays yours, not because you are guarding it moment to moment, but because it lives outside their folder entirely.

A second set of house rules

In Part 1 you wrote a root file that tells your assistant how to work with you. A helper gets their own, shorter version: what their job is, what they are allowed to touch, and how you like things done. When they open their folder, their assistant reads those rules and works inside them, the same way yours does for you. You are cloning the good habits, not your whole business.

What their folder never sees

Your keys, your passwords, and your private records live outside the helper's folder. They are not tucked away or hidden by a polite request, they simply are not in there. A helper, and a helper's assistant, cannot pass on what they were never handed. It is the same safe-by-shape thinking behind the assistant you built in Module 9, now protecting you from a very human kind of accident.

Rules as a contract, not a hope

The non-negotiables go in writing: what to never touch, what to always check with you first, how to handle anything sensitive. These are behavioural rules the helper's assistant follows even when you are nowhere near. The boundaries are written into the folder, so they hold on a busy day without anyone having to remember them.

Two kinds of seats

This module adds seats to your system, and there are two kinds. A seat for a person, which this lesson builds, and a seat for an AI agent, which the next lesson builds. A person gets a folder, a machine, and access of their own. An agent gets a small file and a permission list, and it works inside your own session. The rest of the module keeps the two apart on purpose: people take the work that needs judgment and relationships, agents take the work that is repeatable and checkable.

Mark complete Next: The AI seat

The AI seat 🤖

Some of the seats in your system will never hold a person, because some of the work you are ready to hand off is repeatable, checkable, and quietly time-consuming. That work can go to a named agent: a worker you spin off from Claude, with its own rules and its own access, sitting in your system the way your skills do.

The setup is one small file in your agents folder holding three things: a name, a line saying when work should go its way, and the list of tools it may use. That last line is the whole of its reach. The reviewer agent in your module pack may read files, search them, and find them, so it can check everything and change nothing. Your helper's boundary is their machine; an agent works inside your session, so its boundary is the permission list you wrote, and it holds by itself.

The stranger test

The reviewer earns its seat because of what it arrives without: your context. When the session that did the work checks its own work, it remembers why it made each call, so it mostly agrees with itself. A fresh agent starts empty. It gets your written rules and the changed files, and what is actually on the page is all it can judge, which is exactly how the work will look to a client, a helper, or anyone reading it cold.

The loop is short: work gets done, the reviewer reads it against your rules with fresh eyes, and it brings back three lists, safe to accept, needs a look, open questions. You read the report and decide. It is the same rhythm as the pull request in the next lesson, with an agent sitting in the reviewer's chair.

Run this loop before you speed anything up

The test matters most at one specific moment: right before you let Claude move faster. In Module 2 you saw that Claude asks before it acts, and that a "don't ask again" answer becomes a standing rule. In Module 8 you built routines that run whole jobs on a clock. Both are real speed, and both remove the same thing: the moment where you would have looked.

So the order is fixed. The review loop comes first, and the speed comes after. Before a job moves to a routine, and before you tell Claude to stop asking about a kind of action, a reviewer with none of the job's context should already be checking that work against rules you wrote down. If your rules are too thin for a stranger to check, that is the honest signal the job is not ready to run without you. And an agent only ever runs when something sends it work, your session or a routine from Module 8; nothing in your agents folder watches your business or wakes up on its own.

A person or an agent?

The sorting rule for every job you want off your plate: anything that needs judgment, a relationship, or someone accountable goes to a person in a scoped seat. Client conversations, decisions with money in them, anything another human will feel. Work that is repeatable and checkable goes to an agent: reviewing changes, checking rules were followed, reading long material and reporting back. Agents prepare, people decide, and nothing leaves your system for another human's eyes without a person pressing send.

Mark complete Next: Collaborate through GitHub

Collaborate through GitHub 🔗

When two people work on the same system, the danger is simple: you both change the same thing, and one of you quietly overwrites the other. GitHub is the tool that solves this. Think of it as one shared online copy of your whole system that two people can both work from safely, with a clear way to look over changes before they become real. As a bonus, it is also an offsite backup of everything you have built.

You do not need to become technical for this. You need the shape of it, so you can set it up with Claude and trust what it is doing.

One shared copy, two people

GitHub keeps the main copy of your system online. You and your helper each work from that same copy, and it quietly keeps track of who changed what. Nothing gets lost in a crossed wire, because there is one shared source both of you are working from, and it remembers every step.

Work on your own copy first

Instead of editing the live system directly, each person works on their own working copy, which GitHub calls a branch. You can try something, get it right, and only then bring it into the main copy. Anything you are still experimenting with stays on your own copy and touches nothing real until you decide it is ready.

Changes get a look before they join

When your helper is ready, they offer their changes for you to review. GitHub calls this a pull request, and it is exactly what it sounds like: a request to pull their work into the main copy. You see precisely what changed, you comment or approve, and the agreed rhythm is that nothing joins the main copy until you have looked. Every change is recorded by name and reversible, so even a slip is visible and undoable rather than silent.

It doubles as your backup

Because the shared copy lives online and remembers every version, it is also a safe offsite backup. If your laptop stopped working tomorrow, your whole system is still there, every version of it, ready to come back. This is the same GitHub you can use to keep a safe copy of everything you built, so the collaboration setup and the backup are one and the same thing.

Two settings you get right up front

Two choices make this safe, and you make them once at the start. First, set the copy to private, so only you and the people you invite can see it. A GitHub copy can be public to the whole internet or private to your invited people, and yours is private. Second, keep your keys out of it: your passwords, your database key, and your .env file never go into the shared copy, the same way they stay out of a helper's folder in the first lesson. Ask Claude to set both before your first upload, and to confirm your keys are excluded, so your system is backed up and shared without any of your secrets going online.

The loop, step by step

Every piece of work follows the same loop, and each step is one button in GitHub Desktop (a free app; Guide 101 covers installing it) or one sentence to Claude. Here it is in full.

Your helper, doing a piece of work:

1. Pull first. Bring down whatever changed since last time, so the work starts from the current state. In GitHub Desktop: "Fetch origin", then "Pull origin". Or to Claude: "pull the latest changes."

2. Make a branch named after the task, like monday-checklist-notes. Their own working copy, from the previous section.

3. Work, and commit as they go. A commit is a saved checkpoint with a one-line note. Small commits, one per finished thought, make your review readable.

4. Push. Committing saves on their machine; pushing sends the branch up to the shared copy. Until they push, nobody else can see the work.

5. Open the pull request with a line or two on what the change is. This is the "please look at my work" moment.

You, when it arrives:

6. Read the changes. GitHub emails you. The "Files changed" tab on the pull request shows every touched file, additions in green, removals in red. What you see there is everything the merge will do.

7. Let your reviewer agent read it too. "Use the change-reviewer agent to review this pull request against my rules." It reports back: safe to accept, needs a look, open questions. The AI seat from the last lesson, doing exactly the job it was scoped for.

8. Comment or merge. Something off: comment on the exact line, your helper fixes on the same branch, the pull request updates itself. All good: press "Merge pull request". Your press of that button is the moment the change becomes real.

Both of you, after a merge:

9. Pull again, so both folders match the shared copy, and the loop is ready to start over.

Who verifies what

Four separate checks hold this setup together. GitHub verifies who: everyone works logged in under their own account, so every commit and merge carries a name, forever. The pull request page verifies what: the "Files changed" tab is the complete list, with no side door. You verify whether: the working agreement is that merges are yours, they propose and you press the button, and because every merge is named and any change can be reverted, even a slip is visible and undoable rather than silent. And your change-reviewer agent verifies against your rules, catching what tired eyes skim past: a key pasted into a shared file, a rules file edited without a reason. It reads and reports; the decision stays yours.

Mark complete Next: Access that matches trust

Access that matches trust 🔑

A helper needs to see some things and not others, and the safest place to decide that is the database itself, not a promise you both try to remember. In Part 2 you set up a system where different people see different rows. This lesson uses that same power for your helper: they get exactly the access their job needs, and nothing past it.

Different people, different rows

Your database can show one person their own slice and keep the rest out of sight. A helper handling your bookings can see bookings, and nothing about your revenue or your private notes. The limit is set by the database, so it holds even if someone goes looking. You are not asking a person to avoid a folder, you are making sure the door was never open.

A view, not the keys

You can share a dashboard, a single screen your helper opens to do their work, without giving them the keys to your whole system. They see what they need through a window you control, and the master keys stay with you. This is the difference between asking someone to tend one branch and handing them the whole tree, roots and all.

Access you can give and take back

Because access is set by role, you can widen it as trust grows and narrow it the day a project ends, without rebuilding anything. Bringing a helper on, and letting them go when the work is done, becomes a small calm change instead of a scramble to remember what they could reach.

Mark complete Next: Celebrations Keeper

Celebrations Keeper 🎉

A CRM usually remembers deals and tasks. This one also remembers the human things. The Celebrations Keeper is the personal layer of your relationships system: birthdays, anniversaries, the win a client mentioned, the thing they were nervous about before a big week. It is the part that keeps a growing business feeling like a set of real relationships.

The details that make people feel seen

The small personal notes, remembered and surfaced at the right time, are what turn a client into someone who feels genuinely cared for. Your system can hold these right alongside the practical records, so a warm message at the right moment is never left to whether you happened to remember. The care becomes reliable, and it still comes from you.

It surfaces, you show up

The Keeper brings the right moment to you: a client's launch this week, a helper's work anniversary, the follow-up you promised at the end of a call. You still send the note, in your own words. The system does the remembering, and the warmth stays yours. Nothing here writes to people on its own, and that is the point.

Why this belongs in the module about people

As your business grows to include a helper and more clients, the personal thread is usually the first thing to fray. Building a keeper for it means growth does not quietly cost you the warmth that made people want to work with you in the first place. The bigger it gets, the more this matters, not less.

Mark complete Next: The handover test

The handover test 🤝

This is the question everything else was building toward: could your helper run a Monday morning without you? Really run it, not in theory. This lesson is a checklist and a dry run, the honest test of whether you have built a business that runs while you live.

Write down what Monday morning is

The handover starts by naming the real steps: what gets checked, what gets sent, what gets flagged to you. If Monday morning lives only in your head, no one else can run it. Written down, it becomes something a second person can follow, and writing it down is often the first time you see how much you were quietly carrying.

Run it once, with you watching

Your helper does a real Monday morning while you watch and do not step in. Wherever they get stuck is exactly where your rules or your access need one more line. You are not testing the person, you are testing the system you built around them, and every snag is a gift, because now you can fix it before it matters.

The honest bar

A business that runs while you live is real, and it is worth being clear about what that means: the steps are written, the access is right, and a real person can follow them without you standing behind them. The test is passed the day you can take a week off and trust that Monday still happens.

This is the whole promise

Everything from Part 1 onward pointed here. A system that knows you, runs your business, earns its keep, and now holds other people. So the reason you built all of it, a life with room in it, becomes something you can actually take, not someday, but the next week you choose to step away.

Mark complete Next: Give a client a home

Give a client a home 🏡

You have held your helpers and your agents. Now hold the people your business is actually for: your clients.

The Client Garden is one place a client logs into and stays. It holds the proposal you sent, the agreement they signed, what they have paid and what comes next, a board of every step tagged to whoever holds it, the record of every session, and the resources you have given them. One client, carried from the first call to the last, whether you coach or consult.

It has two faces, on purpose. Your client sees a calm view: their own work, scoped to what they have paid for. You see all of it, and you run every client's garden from one screen. Every move is a single write to your own database, so a card you drag in a session shows up in their browser, and theirs shows up for you, in sync.

Here is the part that protects you. When you send a proposal, the client sees your read of their problem, and your plan stays locked until they agree. Your database holds the recommendations back until there is a yes. Your thinking stays yours.

You build the agreement from your own template or a PDF. They sign with a tick, and paying opens the rest. From there it is the board: drop a call transcript in from any tool and it becomes tagged next steps, sitting where you both look.

It runs on your Supabase, in your brand. Open it in demo mode first and click every corner. Then Guide 106 makes it yours. Thirty minutes once, two minutes per client after.

Mark complete