Start here · Lesson 2 of 3
Who are the six YAGNI Workers and what does each one do?
Published September 8, 2026
Six named agent Workers, each a craft with a boundary. Bailey proposes from your backlog, Reeve critiques the plan, Wright builds to a draft pull request, Proctor reviews it, Fletcher tests it in a browser, and Harper reports what happened. Each is engaged onto a Team, and each starts at Training.
What is a Worker?
A named agent teammate defined by its craft. A Worker is not a persona and not a chatbot: it has inputs it reads, an artifact it produces, and a ceiling it cannot climb past no matter how good its record gets. That ceiling is what makes it safe to engage on day one.
Workers serve Teams, and the same Worker can hold different authority on two Teams. Below, in the order the work moves.
What does Bailey do?
Bailey is the Product Manager, and it runs on weekday mornings or when you ask.
Reads the backlog attached to the Team, a Jira project or epic or a Linear project, plus the Team’s Responsibilities and the decision ledger.
Produces a few proposals at a time, ranked and readiness-checked, each with the evidence it came from and what it is expected to move.
Never ships. A proposal always waits for a person, and Bailey reaches Supervised at most.
What does Reeve do?
Reeve is the Staff Engineer, the critic on the planning side. It speaks when a plan is ready.
Reads the plan, the Team’s Playbook, and its watch-set: migrations, auth, new dependencies, data deletion, and anything else you add.
Produces a critique in place: concerns, tightened wording, or a plain no concerns. It stays quiet on routine work.
Never authors the plan and never blocks it. Reeve is advisory, and it reads best with a role note from you: what to watch for on this Team.
What does Wright do?
Wright is the Builder. It works the queue, capped by the throughput you set.
Reads the approved plan, the repository in a cloud sandbox, and the decision ledger, so it does not re-decide what you already settled.
Produces commits and tests on a branch, a draft pull request, and answers to review rounds up to the cap you set.
Never merges. The pull request is the finish line at every rung of the Ladder.
What does Proctor do?
Proctor is the Reviewer. It wakes when a pull request opens.
Reads every pull request on the repositories the Team attaches, through its checks: deep review, business fit, database, security, tests, and any check you add.
Produces one review, with the findings it discarded readable behind it, then follow-ups on each new commit until the pull request is clean.
Never blocks a merge. It approves only once its Engagement has earned that; before then it advises and flags.
What does Fletcher do?
Fletcher is QA, in beta. It runs when a pull request changes.
Reads the exact revision and the Team’s repository environment: the primary repo, its dependency repos, setup commands, services, secrets, and the auth mode.
Produces a test plan written from the change, deterministic tests first and then bounded browser exploration, with screenshots, a video, and a verdict attached to the pull request.
Never changes application code and never weakens a test.
What does Harper do?
Harper is the Chronicler, and it files on weekday mornings.
Reads the Team’s work items and their receipts, plus the channels the Team reports to.
Produces the Brief, the standup in Slack, and release notes on request, with whatever needs a person named and linked.
Never acts. Harper reports only, and a quiet morning stays quiet.
How do you engage a Worker?
You pick it from the roster and give it an Engagement on a Team: when it runs here, what it may do alone here, and what it knows here. Every Engagement starts at Training, where nothing moves without you, and climbs on its own track record. Fletcher also needs a repository environment before it can boot anything. To see the six of them carry one ticket together, read your first work item.
Common questions
Do I have to engage all six Workers?
No. Most teams start with one gate. Proctor, Reeve, and Fletcher only check output: they never change code, and they run beside whatever review you run today. Engage one on one repository, read its findings next to your current reviewer's, and add the builders when the record earns it.
Can I rename a Worker?
Yes. The names ship as defaults and are renamable per workspace. What does not change is the craft underneath: the inputs it reads, the artifact it produces, and the ceiling it cannot climb past. One identity per Worker across the workspace, with cadence and authority set per Engagement.
Is Fletcher ready to use?
Fletcher is in beta. It boots the app in a sandbox against your repository environment, writes a test plan from the change, walks it in a browser, and attaches the video and screenshots to the pull request. It never edits application code, so the worst case is evidence you disagree with.
Do the Workers all run the same model?
No. Every task is sized before it runs and routed to a vetted, US-hosted open weight model that fits it. Reeve reads plans on the strongest reasoning available because a bad plan is the expensive mistake; routine work never pays top rates. It is one rate card either way.