Set up your email department

What you do: start the setup with your Chief of Staff and say yes to the privacy check and your profile. What you get: customer email kept out of anything that gets saved to GitHub, and every date the team uses worked out in your time zone.

Why privacy comes first. Your workbench is saved to GitHub at save points. Once your mailbox is connected, customer email lands in your workbench, and none of it may ever be saved there. Your workbench keeps a "never save" list of folders. Gigawatt checks that list covers the folders where mail will land, and that nothing private was saved before. (Gigawatt may call this list .gitignore.)

If you did Week 2's Gmail bonus, expect a pause. Some of those emails were already being saved. Gigawatt shows you which, and offers to stop saving them. Your files stay on your computer. Nothing is deleted.

Why your time zone matters. The team works out every "Saturday" and "next week" from your profile, never from its own guess at the date.

Do this now: start the setup

In a new thread with your Chief of Staff, aibl-chief-of-staff, say:

What you should see

1. Gigawatt's privacy check, with one of three answers:
   • All clear. Nothing to do.
   • The "never save" list is missing some folders. Gigawatt shows exactly what it would add. Nothing already there changes. Say yes in your own words. Your mailbox can't connect until this is done.
   • Private files were already saved. Gigawatt lists them and offers to stop saving them. Read the list, then say yes. Nothing is deleted.
2. The exact lines for your profile, before they're written. Say yes. Gigawatt reads them back to you once saved.

More: why the pause happens, and how dates are worked out.

What you do: sign in to your email in your app, then say yes to which agent gets which mail tools. What you get: your mailbox connected. The team can read and save drafts, and every send waits for you.

You give access in two steps. First you sign in to your email in your app. Then you say yes to which agent may do what with it:

• Newman may only read.
• Your Chief of Staff may save drafts. In Codex Outlook Email it never sends; routes where the Chief can send elsewhere still need your approval.
• Sallee keeps read-only access only if you want it to.

How sending works. With Outlook Email in Codex, the team creates and checks a reply draft, and stops. You inspect it in Outlook and decide whether to send it yourself. The Chief never uses a send tool, a browser or computer control to send it. A held or practice draft must not be sent by you either. The next lesson explains the checks before a manual send. Other routes where the Chief can send keep their own checks and approval step.

If your company controls your email, ask whoever manages it before you connect.

More: other email, step by step.

If you connected Gmail in Week 2: a read-only connection can stay with Sallee or go, your choice. If it could also send, Gigawatt takes it off on your yes and connects Newman read-only instead.

Practice mail. The made-up emails you use in the next lesson can never be sent.

Do this now: sign in, then tell your Chief

Sign in yourself. No agent sees this screen.

• Claude Code: Settings, then Connectors, then your mail connector, Connect, and sign in.
• Codex: Settings, then Apps or Plugins (your version shows one of the two). For Microsoft 365, choose Outlook Email, Connect, and sign in yourself. If approval is required, ask your administrator; do not change accounts or routes to get around it.

Then, in the same Chief of Staff thread as Part 2, say:

What you should see, in order

1. The Chief asks for a short name for the account (like shop-gmail) and your address.
2. Gigawatt shows exactly which tools each agent would get. For Codex Outlook Email, Newman gets search and fetch; the Chief gets fetch and create reply draft. Nobody gets a send tool or the whole connector. The details give the exact names for Gigawatt; you do not type tool identifiers. Say yes only to the displayed plan.
3. A guide to the access this route actually needs. For Codex Outlook Email, the grants stay limited to those read and reply-draft actions; a permission to send is not part of setup. On other qualified routes, the Chief explains the app's approval controls. A written role rule in Codex is not proof that the host chat cannot access another tool.
4. One read-only listing test. The student display can show sender and time, but Outlook's response may include subject and message text. Agree that reading scope before the test. Nothing is drafted or sent.

More: who gets which mail tools.

What you do: ask your Chief of Staff to survey your recent mail, then say yes to the category changes you want. What you get: email categories that fit the mail you actually get, before your first observational eval.

Your categories are the kinds of email the team sorts into, each with what normally happens to it: the team drafts a reply, it comes to you, or it is skipped. They start as the course's list. The survey shows what your own inbox holds, so you can make the list yours.

The survey requests sender, date and mail tab from up to 300 items in the last 30 days. A connector may return more: Codex Outlook Email can include subject and message text with its listing. Agree that scope before searching, or leave the survey for later. No separate fetch, marking as read or labeling is authorized by the survey. On Outlook, listed items are messages, not a count of distinct real conversations. A script counts the returned evidence; missing fields stay unknown.

Do this now: ask for the survey

In the same Chief of Staff thread, say:

What you should see

1. A short summary: your top kinds of email, who writes most, and how much looks automated.
2. Two to five new or changed categories, each with what normally happens to it, and any sender domains to always skip or always bring to you.
3. The exact changes, numbered. Say yes to the ones you want, or say what to change.

More: how the survey counts, and what it saves.

What you do: tell Echo what it may read, then approve the guide it writes. What you get: your voice package: a short "how I write" guide the writer follows on every reply.

"Calm, kind, short" can mean different things. Your writing samples show Echo what you mean. It proposes style rules with supporting quotes and lists what the samples do not cover. The guide describes your writing, never facts about your work.

1. You say what Echo may read. Nothing is read until you say yes to the list.
2. The samples are gathered from what you named. They stay on your computer and are never saved to GitHub.
3. Echo writes the guide, with its gaps, marked for your review.
4. You approve it in your own words. The Chief saves it only on your yes.

Do this now: give Echo its list

In the same Chief of Staff thread, say:

Check the list it reads back: only what you named, with dates, and what stays out. Correct it, or say yes.

Read the guide's dos, don'ts and gaps. Ask Echo to correct wrong rules; approve it only when it is right.

What you should see: your guide saved in work/course/staff/voice-package/, marked approved, with your words and the date.

More: what Echo reads and what is saved.

What you do: tell your Chief where you'd look to answer a few of your emails. What you get: those places connected read-only, each tested once, so Hatch can answer from them.

Why: the team needs the places you check yourself, such as prices in a shared drive, bookings in your calendar or policies in Notion.

Your Chief asks about the 3 to 5 emails you have in mind, one at a time: "If you answered this email today, where would you look?" Describe each email in one sentence. Don't paste the email itself.

For each place you name, four things happen before the team uses it:

1. The Quality Reviewer (Kansa) checks the plan for connecting it.
2. Gigawatt connects it so the team can read it, but never change it.
3. Hatch looks up one small thing there, and you check it's right.
4. The place goes on your source map: the list of places Hatch is allowed to read.

If a place can't be connected, save a copy of what's in it as a file, or tell the team the fact yourself.

Nothing in these places gets changed. For example, nobody books, moves or cancels anything in your calendar.

Do this now: run the interview

In the same Chief of Staff thread, say:

When the Chief names a place, connect it yourself in your app first (Claude Code: Settings, then Connectors. Codex: Settings, then Apps or Plugins), then tell the Chief in the same thread. Nobody signs in for you.

What you should see: for each place, Kansa's checked plan, your yes, a test pull you recognize, and a line in your source map.

More: the checks, and Codex.

What you do: find, in an agent's own file, what keeps Hatch off the web. What you get: you can tell a rule the app enforces from one the agent only follows.

The External Researcher (Scratch) is the only agent on your email team that goes on the web. It checks outside facts that change, like a holiday or a closure, dates every fact, and keeps private details, like a customer's name or order number, out of every search.

Hatch never goes on the web. There are two ways an agent can be kept from doing something:

• A lock. The app stops it, because the tool it would need isn't in its file. Like a door with no key.
• A written rule. The agent's file says not to, and the agent follows it. Nothing in the app stops it. Like a "please don't enter" sign.

A lock always holds, so you can rely on it. A written rule usually holds, but the agent could slip, so check its work. In Codex, every limit is a written rule, because Codex can't take a tool away from one agent. So if you use Codex, check more closely.

Do this now: find the lock in Hatch's file

Back in your Professor thread from Start or resume, say:

Look in "What you never do". In Claude Code, Hatch's tools line has no web tool, so it's a lock. In Codex, it's a written rule. Then find the two web tools in Scratch's tools line.

More: Scratch's tools, and Firecrawl or Exa.

What you do: read the twelve questions the Quality Reviewer (Kansa) asks of every draft, and pick the one that matters most to you. What you get: you know what "ready to send" means before you see your first draft.

Why a separate reviewer. Kansa checks every draft version independently of the writer: a second pair of eyes before a reply goes out.

The twelve questions. Kansa asks the same twelve questions of every draft. Each one gets a pass or a fail, with a quote from the draft that shows why.

The three marks, and what happens next. After the twelve questions, Kansa gives the draft one of three marks. When in doubt, it picks the more careful one.

A draft with a blank left for you is never marked ready to send. The blank is how the team avoids making up a fact, so it isn't counted against the writer.

Do this now: read the twelve with The Professor

In the same Professor thread, say:

Keep your answer. If a draft ever gets past Kansa with something you'd never send, that's the rule to add as a note for Kansa. More: the twelve, in order.

If you get stuck

More answers: when you get stuck.

What you'll keep

Your profile, your connected mailbox with every send waiting for you, your email categories, your approved voice package, and your source map. All of it is saved in your own records under work/course/staff/, which a course update never changes.

Before you finish

You can also say which agent reads your email and why, and how a lock differs from a written rule. Self-assessed. No gate.

Words you now own

• Card: Newman's short summary of one email.
• Prompt injection: instructions hidden in something an agent reads, like an email, trying to make it do something you didn't ask for.
• Pile: where the Chief sorts an email: Needs you, Team, Handled or Skipped.
• The record: the files under runs/ where the team writes down everything it did.
• Voice package: your "how I write" guide. Never used as facts.
• Source map: the places Hatch may read, each tested and approved by you.
• Lock or written rule: the app enforces a lock; a written rule is only in the agent's file.

Next: Run three observational evals, then review and send. Your email team is connected and ready for its first trial.