Give each agent its tools, and put the team on the record: the details

This page goes with the lesson "Give each agent its tools, and put the team on the record". You don't need it to finish the lesson. Read it when you want to know how a step works, or when something goes wrong.

Why your Chief needs a record

Your Chief of Staff sends work to a team only from that team's record. It never works out a team from memory or from the design alone. The record is the one place that names the five agents for this work and where each one comes from, so a job reaches the same agents every time. The record is paperwork, not a decision: it writes down the team you installed, so it is filed with the install, on the yes you gave there, and you read it afterwards.

The record, line by line

The record is one short file, work/course/staff/teams/<id>.md. The <id> is the team's short name, like monthly-newsletter, and it matches the file name.

• id, name, department: the team's short name, its full name, and the department it belongs to.
• work_stream: your work in one line, from what starts it to what it delivers.
• design: the PRD the team came from, by version. It must be a file in your job folder, runs/<job>/design/prd-v<n>.md.
• recorded_on: the date the record was saved.
• owner_yes: your install yes, word for word, as the install receipt recorded it (or your pre-authorization line, when the install went ahead on it).
• members: one line per role, written agent | role | kind | skills.

Where the kinds come from. The Charter Steward reads each agent's department from your registry, the list of every agent you have. It never takes the department from the design. So "new", "reused" and "borrowed" always match where each agent actually lives.

Skills. A skill is a written method an agent follows, like the Quality Reviewer (Kansa)'s review checklist. The skills on a member line are the ones this team uses. skills: none means the team uses none of that agent's listed skills, and that is fine. If Gigawatt built an agent a skill for your team at install, it is listed on that agent's line. Your Chief names each agent's listed skills in every work order it sends for this team.

The proposal. The Steward writes its proposal to runs/<job>/team-record.proposed.md (in a background build, runs/<job>/setup/team-record.proposed.md). Your Chief files it with the install receipt, unchanged except the owner_yes line.

The team check

When the record is filed, the Steward files your install yes as a ruling in work/course/staff/decisions/, with the install receipt as its evidence, and runs the team check, team_check.py. The check only reads. The OK line means all of these are true:

• every agent on the record is in your registry
• each of the five roles is filled once, by five different agents
• the lead is new, the specialist is new or reused, and the quality reviewer is not new
• each kind fits the agent's department: new and reused agents belong to the team's department, borrowed ones to another
• each listed skill is one that agent has
• your install yes is in the record, and a ruling in your decisions names the record
• the design file is in your job folder

The Steward never changes your registry, your design or an agent to make the check pass. If something is wrong, it tells you, and your Chief files a corrected record on your word.

Every PROBLEM line, and what to do

Reading the listing

When you ask your Chief which agents do the work, it answers from a listing of your team records. Here is the full listing for the made-up newsletter team:

• Read, Glob, Grep: the agent reads and finds files in your workbench.
• Write: it saves files in your workbench. Nothing outside it.
• WebFetch, WebSearch: in Claude Code, the agent's own web search and web page reading. The External Researcher (Scratch) has these from the start.
• connectors: any connected tool you gave that agent, like a mail account or a research tool. "none" means you haven't given it one.

The tools come from your registry, not from the record. That is why the record doesn't change when you give an agent a tool.

In Codex

In Claude Code, an agent can use only the tools on its line. That's a lock.

In Codex, every agent can use a tool you connect on the Plugins page. The tools and connectors lines are written rules there, kept by each agent's own instructions: Scratch's instructions keep web search to Scratch. Your records still name the one agent that holds each tool. The course accepts this for research tools, because Firecrawl and Exa only look things up. They can't send or change anything. Any tool that can send keeps its ask rule.

The connect step

Connecting a tool in your app makes it visible to the app. It doesn't decide which agent may use it. Gigawatt's connect step does, on your yes.

Tool names come from your app. Gigawatt reads the tool's names from the app, or asks you to read them off the connector page. It never runs the step, not even the preview, on a name it guessed. If it calls a name "unverified" or says it "follows the pattern" of another tool, it hasn't seen it. Give it the names. A yes doesn't replace them.

The send tools. Gigawatt marks every tool that sends, posts, replies, publishes, books or schedules something as a send tool. When it is unsure, it counts the tool as a send tool: an extra ask costs you one click, and a missing one could cost a message you didn't approve. Each send tool gets an ask rule.

What the preview shows. Which agent gets which tool, which of its tools send, that your app asks you before each send, and the files a yes changes. The preview itself changes nothing outside your job folder.

What a yes changes. All four of these, or none of them:

• a line in your connector record, work/course/staff/connectors.yaml
• the agent's tools line in your app
• an ask rule for each send tool, in your app's settings
• your registry

Gigawatt then runs the drift check, which compares your registry with the agents in your app, and saves the result in your job folder. The course's own files are never changed, so a course update has nothing of yours to overwrite.

Why you restart your app. An agent loads its tools when a thread starts. Close the app, open it again, and start a new thread before you check.

Changing the team later

A new skill on an agent's line is paperwork: the Chief files the updated record with the install that added the skill, and the team check runs again. A different agent or role changes what the team may do, so it starts with Archie as a new PRD version and your yes to it; the record follows that install.