More detail: Design a team for your own work, with Archie

This page goes with the lesson "Design a team for your own work, with Archie" (course/workforce/week3/lessons/anw-w3-l05.md). You do not need it to finish the lesson. Read a section when the lesson links to it.

Picking the department

Your new team goes in one of the six departments on your roster: Customer Support, Marketing, Operations, Quality, Sales or Growth. Sales has no agents yet, and Growth has only role drafts, so a team there starts with its own new agents and borrows the rest. If your work fits none of the six well, pick the closest; a brand-new department is a later build. The department is where the team's new agents live; borrowed agents keep their own home.

Fast Track and Full Track

Archie has two ways to work.

• Fast Track asks about ten questions, then writes a first PRD with the gaps marked in plain view. It is the course default, and this lesson uses it. Plan on about half an hour of your time.
• Full Track goes through five phases and writes no PRD while anything critical is still open. It takes longer. Switch to it at any time by telling Archie so, in Archie's thread.

What Archie asks about

The questions that change the design come one at a time. Easy facts, like names and how often the job runs, may come in a small batch. Archie covers:

• the problem, and who gets the result
• what done looks like, and the smallest version worth running
• what the team must refuse
• your steps today, and which tools the work lives in. Then it asks once whether it can look through them, and writes examples.md and current-practice.md in your design folder from what it finds
• what the work needs to know, and the tools it needs: "Here's what you've already connected; which does this work touch, and what's missing?"
• where you decide
• how you will know it worked

Archie skips anything your records already answer. Every few answers it plays back what it has and what it does not know yet.

Research, and questions for Gigawatt

"Go research it." Archie never searches the web itself. It writes one question for the External Researcher (Scratch), sends it, and adds the answer to the PRD with its source and date. Your private details, client names and anything from your records never go into a search. If Scratch cannot reach the web from your app, Archie tells you plainly and gives you the exact search to run yourself. Save what you find as a text file in library, approve it as in Part 2 of the lesson, and tell Archie it is there. Or say "Leave it UNKNOWN."

Questions only Gigawatt can answer. Some questions are about your setup, like whether a tool is on your roster. Archie writes the question to questions-for-gigawatt-1.md in your design folder. A fresh copy of the Operator (Gigawatt) answers in answers-from-gigawatt-1.md, and Archie quotes that file by name in the PRD. Asking builds nothing. Your Archie and Gigawatt threads never message each other: they pass files.

When something is still open

• UNKNOWN. After two tries at a question you cannot answer, Archie writes it down as UNKNOWN: and moves on.
• ASSUMPTION. When you say "Use your best judgment", Archie offers a guess in one line and waits for your yes. Only then does it go in the PRD, as ASSUMPTION:.
• A critical gap. On Fast Track, a critical gap does not stop the first PRD. Archie writes it anyway, lists the gap in section 7, and keeps the status at Draft. You answer it, or agree to carry it as an assumption, next lesson.

Every file in your design folder

Everything Archie writes goes in your job folder, under design. It only ever adds new files. A change is a new version, like prd-v2.md, never an edit to an old one.

The check and the Checked by line

A clean copy of Archie reads the PRD, the spec files and the five-role playbook, and assumes the PRD is wrong. It writes its findings first: the section, the line, and what is wrong. Then it lists up to five things it could not verify. Then it scores five areas from 0 to 10 (job, structure, clarity, completeness, and whether Gigawatt could build from it) and suggests its top three fixes, F1 to F3, each a before and after of one line. A fix never adds a number you didn't give, never brings back something you left out, and never loosens a "never". The scores decide nothing: the status comes from the findings. It fixes nothing. A change is your call, and it makes a new version, which gets its own check.

The card's Checked by: line names the model that ran the check, and one of two labels:

• Independent check: the same kind of model that wrote the PRD, starting with a clean slate.
• Second-model review: a model from a different family.

If it reads not checked yet, the check has not run. In Archie's thread, say: "Run the check on prd-v1 before I review it."

The status line. A PRD reads Draft while a critical gap is open, and Ready for review when none is, the format is clean and the check has run. Archie never calls a PRD approved, complete or ready to build. Only your yes, naming a version, approves it.

The flow drawing

Section 3.3 of the PRD holds the flow as a Mermaid block: plain text that some apps draw as a picture. If your app shows it as text, read it top to bottom. Each line is one step and the arrow points to the next. The lesson shows the made-up newsletter team drawn out.

The seven questions

Section 4 of the PRD answers seven questions for each new agent:

1. Is the job recurring?
2. Does it need its own judgment?
3. Does it need its own knowledge?
4. Does it produce a named piece of work?
5. Does no existing seat already own it?
6. Can its quality be measured?
7. Is there a condition for retiring or changing it?

It is a check, not a gate. A "no" does not stop the agent. It is written down with what it costs and what would change it, and you decide with it in view.

The newsletter's five cases

Archie drafts the five test cases from your answers, always the same five kinds. Each has an Input:, a Should:, a Fails if: and a Run count: line. Here they are for the made-up newsletter:

Run count. The refusal case runs three times, because a refusal that holds twice in three is not a pass. The others run once.

The held-out case. Archie keeps one of cases 2 to 4 back and marks it held_out: true (case 4 in the example). The Operator (Gigawatt) never sees it while it builds the team. It runs only after the build, in the check and in the suite, so the team is built for the job, not for the test. It stays in your design; only the build is kept from it.

Later in the module, each case runs as an observational eval with TOAST. Before a run you write what you expect. Afterward you observe what the team did, analyze why, change one thing, and test that case again. After any change to the team, every case runs again as the suite: that is "running the neighbors", in the lesson "Run five cases and fix what breaks".