Give each agent its tools, and put the team on the record
How does my Chief of Staff know my new team exists, and does each agent on it hold the tools it needs?
- Source
- Internal's lesson, src/sara-week3/internal/lessons/anw-w3-l08.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 part at a time (one part at a time is the lesson; one scroll is kept to compare)
Staff review only: full controlling prompt. Students paste only the short request below.
Use the native aibl-the-professor agent to guide the lesson "Give each agent its tools, and put the team on the record". Read course/workforce/week3/lessons/anw-w3-l08.md completely, its details page course/workforce/week3/reference/anw-w3-l08-details.md when the student asks how something works, and the native aibl-course-guide and aibl-lesson-map methods for this app. You teach and read; you never record a team, file a ruling, connect a tool or run a job for the student. The student talks to the Chief of Staff and the Operator (Gigawatt) in their own threads. Do not call, spawn or route to any agent. Do not edit any file. Never write, suggest or pass on a yes; every yes is the student's own words in the Chief's or Gigawatt's thread.
Use these words exactly. The team record is the Charter Steward's short file for one team, work/course/staff/teams/<id>.md: its name, department, work, the approved PRD it came from, and five member lines, each written seat | role | kind | skills. It was filed with the install, with the student's install yes as its owner_yes; the student reads it today and corrects it on their word, and does not say yes to it. The PRD is the design Archie wrote and the student said yes to, prd-v<n>.md; Archie recorded the version. A seat's kind is new (built for this team), reused (an agent the student already had in this team's department) or borrowed (an agent from another department, which keeps its home there). The team check is team_check.py; its OK line says the record is complete. A ruling is a decision of the student's, filed by the Steward in work/course/staff/decisions/; the record's ruling was filed with the install. A research connector is Firecrawl or Exa, given to the External Researcher (Scratch) through Gigawatt's connect step. An ask rule makes the app ask the student before each send. Say "your work", never "business"; say "you", never "owner". Name agents job title first, nickname in brackets on first use. Name lessons by title, never by number.
Ask open questions only. Never decide for the student whether a record is right or whether an agent needs a tool.
Honesty rule. Never promise more than the lesson page and its details page say.
Part 1. If asked, read work/course/staff/teams/<id>.md and the approved prd-v<n>.md under runs/<job>/design/, read only, and help the student take the page's four checks one at a time: five roles filled by five different agents; the lead new, the specialist new or reused, the quality reviewer never new; each kind right for the agent's home department; the design line naming the version Archie recorded for their yes. The student judges first; then say whether you agree, quoting the line you judge. A wrong line is corrected through the Chief on the student's word; a correct record needs nothing from them.
Part 2. If asked, help the student read the Chief's answer against the team record and section 5 of the approved PRD, read only: which agent holds which tools and connectors, and whether a tool the student chose is missing. In Codex, say plainly that every agent can use a tool the student connects there: a tools line is a written rule in Codex and a lock in Claude Code, and Scratch's instructions keep web search to Scratch.
Part 3. If asked, explain the connect step and the ask rule. Tool names are read off the app's connector page word for word; never supply or guess one.
Otherwise, if asked, explain the step and what the student should see. When the student finishes, the next lesson is "Run five cases and fix what breaks": five test cases run as observational evals with TOAST (say what you expected, observe, analyze, change one thing, test again).
Staff only: status, sources, what is not tested. Not student-facing.
Status: DRAFT, 5 October 2026, for Sara's review. Sara's standard applied (branch gigawatt/aw-week3-sara-l08-20261005): every part opens with what the student does and gets; mechanics, the full team check, the listing, the Codex limits and the connect step's inner workings moved to course/workforce/week3/reference/anw-w3-l08-details.md (source overrides/course/week3/reference/anw-w3-l08-details.md); no test status, timings from tests or lesson numbers in student text or the paste prompt; "owner" and "business" out of student prose (the record's literal owner_yes: field stays in the sample). Every student step and safety action is unchanged: the proposal shown word for word before anything is saved, the four checks, the yes, the OK line, the readback from the record, the tool preview before a yes, names read off the connector page, the ask rule on any send, the app restart. Built against the Exercise 2 merge on gigawatt/aw-week3-release-20261005. Continues from l07 (ends at the Chief because the team has no record yet) into l09 (five cases as observational evals).
What moved in the Exercise 2 rewrite: tools for the new agents are chosen in l07's Align and granted at its install (R16). This page records the team first, reads it back with tools, and gives a short connect path for a tool still missing, usually a research connector for Scratch. Codex Firecrawl is the plain R31 sentence.
Sources: Charter Steward duty 6 and "How you work" step 5 (aibl-charter-steward); workforce/shed/team_check.py (member line seat | role | kind | skills:, the rules, the OK line, --list output, the filed-ruling check); the Chief's team routing line and aibl-team-flow "Before the first step"; aibl-agent-setup "Give a seat a connector" and Gigawatt's "Week 2 connector choice"; Scratch's body and registry row; INTERFACES section 7; MODULE3-LESSON-NOTES-DRAFT, Lesson 4.
Tested, old record shape (2 October, both apps): Steward proposal, save on the yes, the OK line, the Chief naming the team and borrowed agents from the record. Claude Code about 2 min to propose and 1.5 to save; Codex about 7 to propose. The connect step was tested in Customer Support.
PENDING PROBE (the page now states these as plain rules, per Sara's standard): the new member lines with kind and skills, the OK line on them, and the Chief's skills and tools readback (P1, P2); a real research connector and a live search through it (never run; V2 used a stand-in); timings for the new shape.
Build gaps: (1) closed by 75436a7a: aibl-team-flow step 5 now matches Scratch's tools in each app. (2) closed by 2673f359: team-shape.md now uses the three kinds. (3) open: Gigawatt's Deploy proof ends with "one ordinary end-to-end job" recorded in 04-install.md; nothing on this page runs it. The page hands it to l09's case 1. (4) l09's sample plan says Team: newsletter; this page's record id is monthly-newsletter (the id in team_check.py's own docstring). The plan line may show a short label; align if l09 means the id.
Tyler's ruling, 8 October (Codex tools). In Codex every agent can use a connector or plugin the main chat has; per-seat limits are a written rule there and a lock in Claude Code. The page says so plainly in Part 2 and Part 3. A side test the same day defined Firecrawl as an MCP server only in Scratch's Codex agent file (mcp_servers in the agent TOML, Codex 0.159): no agent saw it, Scratch included, so it is not a way to keep a tool to one agent. The course does not use it.
Last lesson the Operator (Gigawatt) built your new agents and installed them on your yes. Each one got the tools you chose. The rest of your team are agents you already had.
Your team is already on the record: one short file that names the five agents who carry this work, and where each one comes from. The Charter Steward proposed it and your Chief of Staff filed it with your install, with your install yes written in. Your Chief of Staff sends work to a team only from its record.
Today you read that record and check it. Then you ask your Chief which agents do the work and what each one can use. If one is missing a tool, Gigawatt gives it one, on your yes: a new tool changes what the team may do, so that one is yours to say.
Your team's record, checked by you, and a clear list of what each agent can use.
Your Chief routes from records, not from memory. A team on the record gets its work the same way every time.
The Course Companion (The Professor) guides you in its own thread. Your Chief of Staff carries the work to the Charter Steward, the agent that keeps your records. Gigawatt handles tools.
You check the record, say so if a line is wrong, and decide whether any agent needs another tool.
Before you start
- Your new agents are installed and proven. Last lesson ended with each one's "prove I work" check.
- Your job folder and your approved PRD. The PRD is the design the Architect (Archie) wrote and you said yes to, for example
runs/2026-10-06-team-newsletter/design/prd-v2.md; Archie recorded the version. If the design changed during the build, the record names the newer version Gigawatt installed from, for exampleprd-v3. - In Codex, you never talk to an agent directly: Codex passes your words on. Start your first message to an agent in a thread with "Ask the Chief of Staff to do this, and show me its reply word for word:" (or "Ask the Operator (Gigawatt) to ..." for Gigawatt). Start every message after that, your yeses included, with "Tell the Chief of Staff this, word for word, and show me its reply word for word:" (or "Tell the Operator (Gigawatt) this ..."). A yes has to arrive exactly as you wrote it.
Start or resume this lesson
Open your prepared workbench, start a new thread, and call The Professor by its role name, aibl-the-professor. Paste only this.
Use the native aibl-the-professor agent to start the lesson "Give each agent its tools, and put the team on the record". Read course/workforce/week3/prompts/anw-w3-l08.txt and course/workforce/week3/lessons/anw-w3-l08.md. Ask me one question at a time and wait. I will talk to my Chief of Staff and Gigawatt in their own threads.
The full instructions your agent follows for this lesson are in course/workforce/week3/prompts/anw-w3-l08.txt.
You ask your Chief to show you the record it filed with your install, and you check it. You get the record, read, and one line that proves it is complete.
The Steward writes, your Chief files.The diamond is you reading it.
What the record says
The record names the team, its department, its work in one line, and the PRD it came from. Then it has one line for each of the five roles: the agent, its role, its kind, and the skills it brings.
An agent's kind says where it comes from:
- new: built for this team. Your lead is always new, and your specialist often is.
- reused: an agent you already had in this team's department.
- borrowed: an agent from another department. It keeps its home there, and joins this team by being named on the record.
the newsletter example (made up for this course)
id: monthly-newsletter
name: Monthly newsletter
department: Marketing
work_stream: one monthly client newsletter, from the month's changes to an approved draft
design: runs/2026-10-06-team-newsletter/design/prd-v2.md
recorded_on: 2026-10-07
owner_yes: Yes, install it.
members:
- aibl-newsletter-lead | lead | new | skills: none
- aibl-hatch | internal knowledge researcher | borrowed | skills: aibl-analyze-business-context
- aibl-scratch | external researcher | borrowed | skills: aibl-research-brief
- aibl-trend-picker | specialist | new | skills: none
- aibl-kansa | quality reviewer | borrowed | skills: aibl-kansa-qa-gate
Here three agents are borrowed: the Internal Knowledge Researcher (Hatch) and the External Researcher (Scratch) from Customer Support, and the Quality Reviewer (Kansa) from Quality. Two are new. skills: none is fine. Each line explained, and where the kinds come from: the details page, "The record, line by line".
Do this now: ask your Chief for the record
In Claude Code: start a new thread, type @ and pick aibl-chief-of-staff. In Codex: start a new thread and begin with "Ask the Chief of Staff to do this, and show me its reply word for word:". Then say this, with your own folder:
Show me the record you filed for the team Gigawatt installed from runs/<job>/, word for word, and the team check's line for it.
What you should see
The record, word for word, from work/course/staff/teams/, with your install yes on its owner_yes line, then the team check's line.
Do this now: check the record
Check four things. The Professor can go through them with you, one at a time, in its own thread.
- Five roles, five different agents. Lead, internal knowledge researcher, external researcher, specialist, quality reviewer. One agent per role.
- The right agent in the right role. The lead is new. The specialist is new or reused. The quality reviewer is never new, and is not one of the agents that produce the work.
- The kinds match where each agent lives. A new or reused agent belongs to the team's department. A borrowed agent comes from another one.
- The design line names the version Gigawatt installed from. For example
prd-v2.md, or the newer version if the design drifted during the build.
If something is wrong, say what, in the same thread with your Chief: it has the Steward propose a corrected record and files that one in its place. If it is right, you are done with Part 1; there is nothing to say yes to.
The line under the record is the team check, with your team's short name in place of <id>:
OK work/course/staff/teams/<id>.md: 5 members, five roles filled, design found
OK means the record is complete. Your install yes was filed with your other decisions as a ruling when the record was saved. A line that starts PROBLEM names what is wrong; see "If you get stuck". What the check looks at: the details page, "The team check".
You ask your Chief, from the record, who is on the team and what each agent can use. You get a list to check against the tools you chose.
Your new lead plans each job, but it can't hand work to other agents. Your Chief of Staff carries every step, and reads the record to know who is on the team.
Do this now: ask from the record
In the same thread with your Chief, say this, with your own work:
Which team handles my <your work>? List its agents, which are new, reused or borrowed and from where, and the skills and tools each one brings. Answer from my records. Don't start a job.
What you should see
Your team's name, the record's path, your five agents, which are borrowed and from where, and each agent's skills and tools. The wording may differ.
the newsletter example (made up for this course; two of the five agents shown)
monthly-newsletter: Monthly newsletter (Marketing). one monthly client newsletter, from the month's changes to an approved draft
record: work/course/staff/teams/<id>.md; design: runs/2026-10-06-team-newsletter/design/prd-v2.md
- lead: Newsletter Lead (aibl-newsletter-lead)
skills: none
tools: Read, Glob, Grep, Write; connectors: none
- external researcher: External Researcher (Scratch) (aibl-scratch), borrowed from Customer Support
skills: aibl-research-brief
tools: Read, Glob, Grep, Write, WebFetch, WebSearch; connectors: none
Read, Glob, Grep, Write means the agent works with files in your workbench, and nothing outside it. Most leads and specialists need only that. connectors: lists any connected tool you gave that agent, like a mail account or a research tool. The whole list, line by line: the details page, "Reading the listing".
Do this now: compare with what you chose
Open section 5 of your approved PRD, or ask The Professor to, in its thread. It lists the tools for each agent. You chose the exact tools for your new agents last lesson.
For each agent, ask yourself one question: can it do its step with what it holds? Write down any agent that is missing a tool. If none is, skip Part 3.
In Codex, every agent can use a tool you connect. There these lines are written rules, kept by each agent's own instructions; in Claude Code they're a lock.
You ask Gigawatt to give one agent one tool you connected. You see exactly what would change, then say yes. You get that agent holding the tool, with your app asking you before anything is sent.
Your design's tools table already named each tool, and Gigawatt checked it before the build, so this step confirms rather than discovers. The usual one is a research connector for the External Researcher (Scratch): Firecrawl or Exa. Scratch can already search the web and read web pages in Claude Code. A research connector lets it read pages a plain fetch can't, or search more deeply. It is optional. Add one only if your team's outside checks need it.
The same step works for any agent and any tool. A new tool changes what the team may do, so it is one of the things you say yes to. Anything that sends, posts or publishes gets an ask rule: your app asks you before each send. That is the default, and sending outside is on the smoke-alarm list: money, sending anything outside, deleting, posting publicly, and account authority always wait for you.
Connect the tool in your app first. In Claude Code: Settings, then Connectors. In Codex: the app's Plugins page. You sign in yourself. Gigawatt never signs you in and never asks for a key. Keep the connector page open: Gigawatt may need its tool names, word for word.
Do this now: ask Gigawatt for a preview
In Claude Code: start a new thread, type @ and pick aibl-gigawatt. In Codex: start a new thread and begin with "Ask the Operator (Gigawatt) to do this, and show me its reply word for word:". Then say this, with your tool, agent and reason:
I connected <tool> in my app. Let the <agent> use it to <what it is for> for my new team. If you can't see its tool names, ask me and I'll read them off my app's connector page. Show me what a yes would change, and change nothing yet.
What you should see
If Gigawatt can't see the tool names, it asks you. Read them off the connector page, word for word. It never uses a name it guessed.
Then it shows you a short list: which agent gets which tool, which of its tools send (a research tool usually has none), that your app asks before each send, and the files a yes changes. Read it, then say yes in the same thread, in your own words, for example:
Yes, give Scratch Firecrawl as shown.
Gigawatt makes the change and checks it. Then it tells you to close your app and open it again: an agent loads its tools when a thread starts. What a yes changes: the details page, "The connect step".
Do this now: check it took
After you reopen your app, start a new thread with your Chief (in Codex, begin with "Ask the Chief of Staff to do this, and show me its reply word for word:") and ask the Part 2 question again. The agent's connectors: line now names the tool. Your team record doesn't change: it lists who is on the team, not their tools.
In Codex: every agent can use a tool you connect; Scratch's instructions keep web search to Scratch. Firecrawl and Exa only look things up. They can't send or change anything.
If you get stuck
| What you notice | What to do |
|---|---|
| The Chief says the team isn't on the record | The record is filed with the install. In your Chief's thread, say: "File the team record from my install receipt in runs/<job>/." Your Chief routes only from the record. |
PROBLEM ... not in the registry, so not available | That agent isn't installed in your registry, the list of every agent you have. Go back to Gigawatt, in its build thread, and ask why. |
PROBLEM ... no ruling in work/course/staff/decisions/ names ... | The ruling wasn't filed with the record. In your Chief's thread, say: "Have the Charter Steward file the ruling for the team record from my install receipt." |
Any other PROBLEM line | In your Chief's thread, say what is wrong; it files a corrected record. Every line explained: the details page. |
| Gigawatt asks for tool names you can't find | Read them off your app's connector page, word for word. If the tool isn't there, connect it first. |
| You told your new lead to run a job | It can't hand work on. Ask your Chief of Staff instead, in its thread. |
| You want to change who is on the team later | In your Chief's thread, say who changes and why. A different agent or role is a change to what the team may do, so it starts with Archie as a new design version and your yes to it; the record follows. |
What you'll keep
Your team's record in work/course/staff/teams/, your install yes filed in work/course/staff/decisions/, and any tool you added, in your connector record.
Before you finish
Check what is on your screen:
You can also say why your Chief needs a record before it routes, what makes an agent borrowed, and why giving an agent a tool is yours to say. Self-assessed. No gate.
Words you now own
- The record (team record): the Charter Steward's short file for a team: its work, its PRD, and its five agents. Your Chief routes from it.
- PRD: the design Archie wrote and you said yes to; Archie recorded the version, like
prd-v2.md. - Kind: new, reused or borrowed. Where an agent on the team comes from.
- Team check: the check that says whether a record is complete. Its OK line is your proof.
- Ruling: a decision of yours, filed by the Steward with your other decisions. Your install yes was filed as the record's ruling.
- Research connector: Firecrawl or Exa, given to Scratch so it can look further on the web.
- Ask rule: a setting that makes your app ask you before an agent sends, posts or publishes.
More background for every part: the details for this lesson.
Next: Run five cases and fix what breaks. Your team runs its five test cases as observational evals, with TOAST: you say what you expect, observe the run, analyze it with Gigawatt, change one thing, and test again.