AI Build Lab / Learn · Agent Workforce · Week 3 · Module 03

Check Archie's design, change it, and approve it

Is Archie's design right for my work, and am I ready to say yes to one exact version of it?

Staff only · this page and its checks

Source: Internal's lesson, src/sara-week3/internal/lessons/anw-w3-l06.md (Internal b518c35b, 2026-10-22 17:15), read by md_week3.py.
Copy: Current Markdown is vendored byte for byte from the Internal commit in Source by vendor_week3.py. Historical publication records: 10-06 Exercise 1 with Sara's yes; 10-07 Exercise 2 and the Module 2 send-route and follow-up fixes, student 58c60d50; 10-08 Exercise 3 and the l05/l11 diagram fixes, student 55061386. Those records do not qualify later Outlook changes. Module 3 and 4 drawings are rendered from the Mermaid in the lesson file (md_week3.py --figures).
Prompts: Word for word from the lesson file Internal ships (course/workforce/week3/). Not run end to end from Learn.
Checked in the app: Not checked in the app from Learn.
Open to students: Yes.
Other view: one scroll (one part at a time is the lesson; one scroll is kept to compare)

Start hereWhat this lesson is, and how to begin

Staff review only: full controlling prompt. Students paste only the short request below.

Use the native aibl-the-professor agent to guide the Week 3 lesson "Check Archie's design, change it, and approve it". Read course/workforce/week3/lessons/anw-w3-l06.md completely and the native aibl-course-guide and aibl-lesson-map methods for this app. You teach and read; you never change the design, approve it, record a yes, or build anything. The person you guide talks to the Architect (Archie) in its own thread. Do not call, spawn or route to any agent. Do not edit any file.

Use these words exactly. The PRD (product requirements document) is the design file, runs/<job>/design/prd-v<n>.md; every change makes a new version with the next number, and earlier versions stay. A seat's kind is new, reused or borrowed. The changelog is the lines under the card of version 2 and up, each marked changed, stands or withdrawn. The check is checker-v<n>.md, written by a clean copy of Archie before their yes; its label is "independent check" or "second-model review", exactly as written on the card. The five test cases in section 2 later run as observational evals with TOAST. The build brief is section 8: one block per new agent. The yes is their own words, for example "yes", "looks good" or "I approve it"; Archie names the version it covers (the newest checked one), and a script, run by a fresh copy of the Operator (Gigawatt), saves their words and that version in approval.json; they never type a version or a hash. The pre-authorization is one line they may add at that yes, "If every case passes, install it; only stop me for a Needs-you item", recorded with the date; it is off unless they say it. Drift is a newer version written after their yes: a wording change is a note in the install report, and a change to what the team may do (a tool, a write path, sending or posting, a borrowed agent, a case) needs a fresh yes naming the change. The pointer line is the one line Archie gives them for Gigawatt's thread in the next lesson. Name agents job title first, nickname in brackets on first use.

Ask open questions only. Never decide for them what to change or whether to approve, and never write their changes for them. Never read out probe ids or test status.

Part 1. Read, read only, the PRD with the highest number under runs/<job>/design/ and its checker-v<n>.md. Show them only the parts the page names: the card (including the status, version and checked-by lines), section 2, section 3.4, the last steps of section 3.1, section 3.5, the skills column in section 4, the tools table and the files listed in section 5, section 8, and up to five "could not verify" lines from the check. Take the five checks on the page one at a time. They judge first; then say whether you agree and why, quoting the line you judge. Tool names written "UNKNOWN until Align" are expected, not a fault. At the end, read their changes back as one numbered list in their words, for Archie. No changes is a valid answer.

Part 2. If asked, read the newest version's changelog and check, read only, and help them see whether each change landed. Never say a change landed without quoting the line.

Part 3. If asked, explain that their yes is recorded against one version, that Archie carries the version so they never type it, and that Gigawatt checks the approval against the files before it builds and again before it installs: a newer version that changes what the team may do stops for a fresh yes; a wording change goes into the report as a note. Explain that the same yes approves the files listed in section 5 for the team's department, once for the batch: the Knowledge Librarian (Sallee) files each one as a source card before the team's first job, with no yes of its own. Explain the pre-authorization line and that it is their choice, off unless they say it. Remind them that the newest checked version is the one their yes covers. Do not open or read out approval.json except to say whether it exists. Never relay, repeat or record a yes, and never say the pre-authorization line for them.

Staff only: what this page promises, and its test status. Not student-facing.

Rewritten 5 October 2026 for the Exercise 2 flow merged on gigawatt/aw-week3-release-20261005. Sources: handoffs/aw-week3-ex2-20261005/lessons/MODULE3-LESSON-NOTES-DRAFT.md (Lesson 2), INTERFACES.md sections 2 to 4, Archie's body ("The files", "The check", "Working with Gigawatt directly"), the PRD template's "What the owner is asked to read", and workforce/shed/design_approval.py record-design.

Sara-standard pass (5 October, evening). Status lives only here. The student text states each promise as a plain rule; no probe ids, no "is built to", no "has not been tested". Every part opens with what the student does and gets. Mechanics moved to course/workforce/week3/reference/anw-w3-l06-details.md (source overrides/course/week3/reference/anw-w3-l06-details.md), linked where first needed: the shortened PRD example and the two "could not verify" lines, the section 3.3 drawing note, the check labels, how Archie handles changes (questions, Scratch, the new check, files not messages), how the yes is saved (fresh Gigawatt copy, script, approval.json), the Codex pointer line, and the after-the-yes rules. The test cases are named as observational evals with TOAST (Part 1, check 2). No lesson numbers in student text or the paste prompt: the Professor routes by the lesson map's id and title, and the prompt names both files by path. "Owner" is gone from student text; the PRD's status string is quoted as "Ready". Every "say this" step names its thread. Every student step and safety rule is kept: the four text boxes are the same requests, the one-message rule, approve only the newest, the named yes, the Codex word-for-word opening, and the second yes to Gigawatt.

Student text now (plain rule)	Probe	Status	If it fails
Part 2: Archie writes the next version with a changelog and a fresh check before asking for the yes	P1, P2	PENDING	Part 2 "What you should see" and the details page change to what ran
Part 3: "Recorded: you approved prd-v2.", `approval.json`, and the pointer line	P1, P2	PENDING	Part 3 "What you should see" changes
Part 3 and details: Gigawatt checks the approval before it builds and before it installs; a changed file stops it until a new named yes	P6 (the script is unit-tested only)	PENDING	Part 3 "If the design changes after your yes" and the details page change
Details: section 3.3 may show as a picture or as text starting `flowchart`	Tyler's desktop sitting	PENDING	none; the page promises text only

Moved to "Build the team with Gigawatt" (anw-w3-l07): staging, RESULT PASS, the setup folder and the old install line.

Open for Sara. The Module 3 banner reads "Week 3 · A team for your own work"; align with the sibling lessons if they chose another.

Tyler's ruling, 8 October (files go through Sallee). The design yes also approves the files listed in PRD section 5 ("The owner's files for this team", new in the template) for the team's department, once for the batch; the Chief has Sallee file them before the team's first job (aibl-team-flow step 4). This replaces the separate approved-sources step that was Part 2 of "Design a team for your own work, with Archie". PENDING: not run in an app.

Tyler's ChatPRD asks, 8 October evening. "What to read" opens with owner-summary-v<n>.md; check 5 adds the check's fixes F1 to F3 and says the scores are not a pass mark; the changelog answers fixes too; the stuck row says "Decide for me". PENDING: no app run yet.

Tyler's asks 2 and 3, 8 October afternoon. Check 4 is now "the tools and skills fit how you work" (section 5's tools table, section 4's skills column), with the build-brief read kept inside it; "What to read" adds section 3.5 (Never, team-wide) and sections 4 and 5; check 2 names each case's Source: line. PENDING: no app run yet.

In plain English

You check your new team's design with The Professor, send Archie your changes in one message, and say yes once, in your own words. Nothing is built or installed today.

Last lesson, the Architect (Archie) wrote that design as a PRD, a product requirements document: one file, prd-v1.md, that says what the team is for, how the work moves, which agents do it, and how you'll know it worked. A clean copy of Archie checked it and listed what it could not verify.

Your yes is the first of two doors. You say "yes" or "looks good"; Archie writes down which version you approved, so you never type a version number. The second door is the install, next lesson. Between the two, your agents stop only for five things: money, sending anything outside, deleting, posting publicly, and account authority.

What you get

One version of your team's design, approved in your own words, one short line that starts the build next lesson, and, if you want it, a standing yes to the install when every test passes.

Why it matters

A design is cheap to change and a built team isn't. Today a change costs one message. After the build, it costs a rebuild.

Your part

You decide what changes, you give the yes in your own words, and you decide whether to pre-authorize the install.

Before you start

You have a PRD from last lesson in your job folder, for example runs/2026-10-06-team-newsletter/design/prd-v1.md, with its check beside it, checker-v1.md. If you already sent Archie changes, your newest may be prd-v2.md. Always work from the highest number.
This lesson uses two threads: a new one with the Course Companion (The Professor), and your thread with Archie from last lesson. Keep both open. Lost Archie's thread? See "If you get stuck".
In Codex, you never talk to an agent directly: Codex passes your words on. Start your first message to Archie in a thread with "Ask the Architect (Archie) to do this, and show me its reply word for word:". Start every message after that, your yes included, with "Tell the Architect (Archie) this, word for word, and show me its reply word for word:". Your yes has to arrive exactly as you wrote it.

Start or resume this lesson

Thread: a new one with The Professor. Open your prepared workbench, start a new thread, and paste only this.

Use the native aibl-the-professor agent to start the Week 3 lesson "Check Archie's design, change it, and approve it". Read course/workforce/week3/prompts/anw-w3-l06.txt and course/workforce/week3/lessons/anw-w3-l06.md. Ask me one question at a time and wait. I will talk to Archie in its own thread.

The full instructions your agent follows for this lesson are in course/workforce/week3/prompts/anw-w3-l06.txt.

Part 1 of 3Check the design against your work

You go through five checks with The Professor. You get one numbered list of changes, in your words, ready for Archie. No changes is a fine answer too.

What to read

The PRD is long because the Operator (Gigawatt) builds from it. You only need these parts:

The one-page summary, owner-summary-v<n>.md: start here.
The card, at the top: the job, who receives the result, what done looks like, the five seats, and the status, version and "checked by" lines.
Section 2: your five test cases.
Section 3.4: which step handles each test case. Also the last steps of section 3.1.
Section 3.5, "Never, team-wide": what the whole team never does, and which step stops it.
Sections 4 and 5: the skills each agent uses (one that already exists, or a new one), and the tools table: what each agent needs, whether you've connected it, and what you still connect yourself.
Section 5, "The owner's files for this team": the files from your library the team will read, one line each, with your reason.
Section 8, the build brief: one block for each new agent.
The check: up to five "could not verify" lines in checker-v1.md.

To see what these parts look like first, open a shortened example.

The five checks

The card says what you meant. The job, who receives it and what done looks like are in your words, or close to them. Each seat has a kind, which says where its agent comes from: new (built for this team), reused (an agent you already have, in this team's department) or borrowed (an agent from another department). The lead is always new. Then read the status line. "Draft" means a critical question is still open, in section 7: answer it in your changes, or tell Archie to carry it as an assumption. "Ready" means none is open.
Your five test cases are right. In section 2, each case has an Input:, a Should: and a Fails if: line, and a Source: line that says which of your real examples it came from, or drafted, no example: the ordinary job, the same job for a different audience, missing information, sources that disagree, and the one the team must refuse. Later in this module the team runs these five cases as observational evals with TOAST: you take the output, observe it, analyze why, stick one change back in, and test again. So would you recognize each case from your own work? Change any you wouldn't.
Every test case has a step, and the finished piece is put together the way you want. In section 3.4, find each case in the right-hand column. A case with no step is a gap. Then, in section 3.1, look at the last steps: who puts the finished piece together, an agent or you? Both work. Change it now if it's the one you don't want.
The tools and skills fit how you work. Does each new agent's tool list match what you actually use for this today, and which skills already exist? Read the tools table in section 5 and the skills column in section 4. A row marked connect names a tool you connect yourself before the build. Then, in section 8, read each new agent's block as if it were a new colleague. Would you know what to hand it, and what you'd get back? Change it if it's vague about what comes in ("some research"), or misses a "never" you'd set for a new hire. Tool names that read UNKNOWN until Align are fine: Gigawatt finds the exact names while it builds.
You've decided about each "could not verify" line, and each fix, F1 to F3. For each one, choose: change the design, give Archie the missing fact, or leave it as it is. The scores are a guide, not a pass mark.

Do this now: go through the checks with The Professor

Open your newest prd-v<n>.md: in your workbench folder, open runs, then your job's folder, then design. Or ask The Professor to show you each part.

Thread: the same one with The Professor. Say this to The Professor:

I'm checking my newest PRD against the five checks on the page. Ask me about one check at a time, let me judge first, then tell me if you agree. Keep a list of the changes I want, in my words, and change nothing. When we're done, read my list back as one numbered block for Archie.

What you should see: The Professor asks about one check at a time, lets you answer first, then says whether it agrees and why. It never decides for you. At the end it reads your changes back as one numbered list. No changes? Go to Part 3.

Part 2 of 3Send Archie all your changes in one message

You send your list to Archie. You get a new version of the PRD with every change in it, a changelog that answers each one, and a fresh check.

Archie never writes over a version. Each round of changes makes a new file with the next number: prd-v2.md beside prd-v1.md. So send everything in one message, and you get one new version with all of it.

At the top of the new version, under the card, is the changelog: one line for each change, finding or fix, marked changed, stands or withdrawn, with the section it touched. Nothing you raised disappears without an answer. In the newsletter example from last lesson, it might read:

## Changelog from prd-v1
- Q1: changed: 3.1, step 7 is now yours: the Newsletter Lead hands you the lines and their sources, and you write the final wording.
- Q2: changed: 2, case 3 Should now says the draft waits for your figures.
- Q3: changed: 5, Hatch reads last month's issue from library/.
- Q4: stands: 2, case 4 keeps its wording; the checker's point is noted in section 7.

Do this now: send Archie your changes

Thread: the same one with Archie as last lesson. In Codex, start with the opening from "Before you start". Paste this, with your numbered list from The Professor.

Say this to the Architect (Archie):

Here are my changes, all in one message. Write the next version with a changelog, have it checked, and show me what changed. Leave everything else as it is.
<your numbered list>

If you have no changes, skip to Part 3.

What you should see: Archie may first ask about a change, one question at a time. Answer in your own words. Then it shows the card in plain words, the status line, what the new check found, and the files it wrote. It ends by asking you to approve it, change it, or set it aside.

Open the new version and read the changelog. Did each change land? If one is wrong, or the new check found something you want to change, send one more message the same way. Each round makes one more version. More detail: what Archie does with your changes.

Part 3 of 3Say yes, in your own words

You say your yes to Archie. You get your approval saved in your design folder, with the version it covers, and the pointer line: one line that starts the build next lesson.

Archie carries the version. "It" means the newest version with its check beside it, and Archie has a fresh copy of Gigawatt run a small script that saves your exact words and that version in approval.json, beside your PRD. You never need to open that file, and you never type a version number. Then Archie gives you the pointer line. It points at your folder; it isn't a copy of the design. For example: "Build the team from my approved design in runs/<your job>/design/."

Your yes approves your files too. The files you named in section 5 are approved for your team's department, all at once. Before your team's first job, your Chief of Staff has the Knowledge Librarian (Sallee) file each one as a source card and adds it to your approved sources. There's no separate yes.

Diagram

If the design changes after your yes. Gigawatt checks your approval against the files before it builds, and again before it installs. A newer version that only changes wording so the design works is drift: Gigawatt goes on and notes it in the install report. A newer version that changes what the team may do, a tool, a write path, sending or posting, a borrowed agent, or a test case, stops the build: Gigawatt names the change and asks for a fresh yes to the new version. More detail: what your yes covers.

Do this now: say yes to the newest version

First read the newest version's changelog and its check. The newest is the one with the highest number.

Thread: the same one with Archie. Say your yes in your own words. For example:

Say this to the Architect (Archie):

Looks good.

"Yes" and "I approve it" work the same way. A hesitation ("not yet") is not a yes, and nothing is recorded.

Do this now: decide about the install, now or later

Archie offers you one line, once. It lets Gigawatt install the team next lesson without asking you again, as long as every test case passes and nothing needs you. If you want that, say it in your own words; if you'd rather say yes to the install yourself, say nothing, and it stays off.

If every case passes, install it; only stop me for a Needs-you item.

Do this now: keep your pointer line

Copy the pointer line Archie gives you somewhere you'll find it. In the next lesson, "Build the team with Gigawatt", you paste it into a new thread with Gigawatt.

What you should see: "Recorded: you approved prd-v2.", with the version Archie recorded, then the pointer line. If you pre-authorized the install, Archie says that too, with today's date. Nothing is built or installed. A new file, approval.json, sits beside your PRD.

If you get stuck

What you notice	What to do
Archie asks you to say your yes again	Your words read as a maybe ("not yet", "hold on"). If you mean yes, say "Yes" in Archie's thread.
You want to approve an older version	Your yes covers the newest checked version. If you prefer an older one, ask Archie, in its thread, to write it again as the next version, then say yes to that.
You want another change after you approved	Send it to Archie in the same thread. It writes a new version, has it checked, and asks again. Say yes to the new one; it takes the place of your earlier yes.
You said the pre-authorization line but want to take it back	Say so in Archie's thread: "Take back the pre-authorization; I'll say yes to the install myself." Archie records the new yes without it.
The status line still says "Draft"	A critical question in section 7 is open. In Archie's thread, answer it, or say "Carry it as an assumption." Then say yes to the version whose status reads "Ready".
The questions keep coming	In Archie's thread, say: "Decide for me on anything I haven't covered, mark each as an assumption, and write the next version."
You lost your thread with Archie	Start a new thread with Archie (in Claude Code, type @ and pick `aibl-archie`; in Codex, begin with "Ask the Architect (Archie) to do this, and show me its reply word for word:") and say: "Read my design folder at runs/<your job>/design/ and pick up from my newest PRD." Archie reads everything from the folder.
You lost your pointer line	In Archie's thread, say: "Give me my pointer line for Gigawatt's thread again."
Archie offers to build or install	It shouldn't, and it won't. Building happens in Gigawatt's thread, next lesson.

What you'll keep

Your design folder: every version of your PRD, side by side, each with its check, and approval.json, which holds your yes, the version it covers, and your pre-authorization if you gave one. And your pointer line for next lesson.

Before you finish

Check what is on your screen:

Before you finishFive checks

I went through the five checks on my newest PRD with The ProfessorI sent Archie my changes in one message, or chose none, and read the new version's changelog and checkI said yes in my own words, in Archie's thread, and Archie said which version it recordedI decided whether to pre-authorize the install, and said the line only if I meant itI saved my pointer line for Gigawatt's thread

Self-assessed. No gate.

You can also say which version your yes covers, what drift is, and which five things stop your agents between your two yeses. Self-assessed. No gate.

Words you now own

PRD: product requirements document, your team's design file, prd-v<n>.md. Gigawatt builds from it.
Kind: where a seat's agent comes from: new, reused or borrowed.
Version: each change makes a new file with the next number. Old versions stay.
Changelog: the lines under the card of a new version, saying what changed, what stands, and what was withdrawn.
Could not verify: a line from the check, naming something it couldn't confirm. You decide what to do about each one.
Two doors: the two moments you say yes: the design (today) and the install (next lesson). Everything else your agents do between them runs without asking, except the five smoke-alarm actions: money, sending anything outside, deleting, posting publicly, and account authority.
Pre-authorization: the one line you may add at the design yes so the install goes ahead when every case passes. Off unless you say it.
Drift: a newer version written after your yes. Wording is a note; a change to what the team may do needs a fresh yes.
Pointer line: the line you say in Gigawatt's thread to start the build. It points at your folder; you paste nothing else.

Next: "Build the team with Gigawatt".