The Academy
Learn to run agent teams, one lesson at a time.
Four short courses, shaped like the four questions every team asks: who the Agents are, how you start a Team, how you train and manage it, and how you work with it from your own tools. Read in order, or jump to the surface in front of you.
The YAGNI Academy is the guided way to learn agent Teams: short lessons, grouped into four courses, that take you from meeting the six Agents and your first ticket to starting a Team on your own tickets, a backlog, or pull request reviews, then managing it on Work and the Ladder, and working with it from your own tools. Each lesson covers one surface or one habit.
Course I
Start here
What YAGNI is, who the six Agents are, and one ticket moving from your tracker to a merged pull request in three clicks. Orientation for the first week.
What is YAGNI and how does it work?
An orientation to YAGNI: agent Teams that mirror your engineering org, six named Agents with boundaries, one ticket moving through six stages with three human clicks, and autonomy set per line and earned on the record.
Read the lesson Lesson 2Who are the six YAGNI Agents and what does each one do?
Bailey, Reeve, Wright, Proctor, Fletcher, and Harper: what each Agent reads, what it produces, and the boundary it never crosses, in the order a ticket moves.
Read the lesson Lesson 3How does your first ticket move from your tracker to a merged pull request?
One ticket, six stages, three clicks of yours: start it, approve the plan Wright drafts and Reeve critiques, and merge once Proctor's review and Fletcher's browser evidence are on the pull request. Done means merged.
Read the lessonCourse II
Start a Team
Connect GitHub, then create a Team at one of three sizes: your own tickets, a backlog, or pull request reviews. Then the connections, the repository environment, and single sign-on.
What is a YAGNI Team, and what are its three sizes?
A Team mirrors one of your engineering teams, never a repository. One noun at three sizes, my tickets, the backlog, pull request reviews, created on one screen. What a Team carries, what its page shows, and when to add another.
Read the lesson Lesson 2How do you start a Team on your own tickets?
The fastest way in: one engineer, one repository, the tickets already assigned to you in Linear or Jira. Create a Team with My tickets selected, click Start on a ticket, approve the plan, merge the pull request. No admin in the loop.
Read the lesson Lesson 3How do you give a Team a backlog so Bailey proposes what is next?
The backlog size: a Team that owns an outcome and works a Linear or Jira project, or a repository's issues, the way a human team does. What Bailey reads, how a proposal is accepted, whose tickets it picks, and how to change the backlog later.
Read the lesson Lesson 4How do you get Proctor reviewing your pull requests?
The pull request reviews size: a Team with Proctor alone, reviewing every pull request opened on the repositories you pick, through its checks, beside whatever review you run today. What it posts, what it never does, and how to add a check.
Read the lesson Lesson 5Which tools does YAGNI connect to, and what does it do with them?
GitHub first through the workspace App, then Linear, Jira, or GitHub Issues for the tickets, Slack for decisions and the Daily Brief, and Confluence or Drive for the export, plus the rest of the native connectors, MCP servers, and custom services.
Read the lesson Lesson 6How do you set up a repository environment so Fletcher can test a pull request?
Begin setup reads the repository, fills in the commands, services, and variables, boots it in a sandbox, and repairs what fails. You add the dependency repos, the secrets, and the sign-in mode. Then Wright builds in it and Fletcher walks the change in a browser.
Read the lesson Lesson 7How do you connect Okta single sign-on to YAGNI?
The full Okta SAML setup for a YAGNI workspace: create the app, exchange the two sets of values, map your admin groups, and turn on the Okta tile. About ten minutes of copy-paste.
Read the lessonCourse III
Train, monitor, manage
Work and the case file, the two rungs of the Ladder, the lines on a Team, the Playbook, the Daily Brief and the reminders, and what to do when an Agent gets it wrong.
How does Work track a ticket, and what is on the case file?
Work is home: one row per ticket in three views, By stage, Waiting on you, and Latest, over six stages. The case file is the ticket's whole record, with every decision it needs resolving in its footer. Add tickets, the rail, and who sees what.
Read the lesson Lesson 2How does the Ladder work, and how does a line become autonomous?
The two rungs a line on a Team is set to, supervised and autonomous, the track record a person reads before moving one, what a reversal does, and the floor that never moves: merge is always a person's click.
Read the lesson Lesson 3What is a line on a Team, and how do Rhythm, Authority, and instructions work?
An Agent on a Team is an Engagement, and its configuration is one line per thing it does there: a sentence with blanks for when it runs, what it covers, and its Authority, plus instructions, checks, and the recent runs. What is on a line's page and how the caps bound it.
Read the lesson Lesson 4How does a Team's Playbook learn your rules?
Where a Team's rules come from, how a proposed rule is adopted or dismissed behind the Playbook card on the Team page, how business rules and engineering guardrails differ, and what a Play is.
Read the lesson Lesson 5How do the Daily Brief and the reminders keep you current?
Harper posts the Daily Brief to your Team's Slack channel each weekday morning: what shipped, what is in flight, what needs a person, with the Receipts linked. And every decision open for more than a day reminds its person each morning. Where each is set.
Read the lesson Lesson 6What do you do when an Agent gets it wrong?
The runbook for a bad run: open it from the case file, read what Proctor discarded, correct it in the moment with Send back or Request changes, let the correction become a rule, Run again, set the line back to supervised, and ask @yagni.
Read the lessonCourse IV
Work from your own tools
YAGNI Code in the terminal and on the desktop, managing Teams from Claude Code or Codex, MCP servers, telemetry, and asking @yagni.
What is YAGNI Code and how do you work with it?
The coding agent your engineers run by hand, as a desktop app or in the terminal: install, the plan, implement, review rhythm you drive, your skills, plugins, and MCP servers, and the models, meter, and record it shares with your Teams.
Read the lesson Lesson 2How do you manage YAGNI Teams from Claude Code or Codex?
Two separate lanes for a harness your engineers already love: add the YAGNI MCP server to manage Teams from inside Claude Code or Codex, and run yagni connect to route that same harness through YAGNI's models.
Read the lesson Lesson 3How do you set up MCP servers in YAGNI Code?
Bring the MCP servers your team already uses into YAGNI Code: repo .mcp.json files work as-is, a one-command import moves your Claude Code setup, OAuth logins open from the session panel, and vendor-approved remote servers are the one honest edge case.
Read the lesson Lesson 4How do you export YAGNI Code telemetry to Datadog?
Send every YAGNI Code session in your workspace into Datadog: one admin setup in Settings, the Datadog direct-SaaS preset fills in the endpoint, and yagni doctor confirms Datadog accepted a real record. Traces, metrics, and log events carry tokens, cost, lane, and tool calls in the same shape Claude Code emits.
Read the lesson Lesson 5How do you ask @yagni for help?
The one right rail on every surface, scoped to what is in the center: one voice with one memory, grounded in the decision ledger, your Teams' record, and the live rows of your connected tools. What it explains, what it starts, and what it never does.
Read the lessonThe best classroom is your own backlog.
Connect GitHub, start a Team on your own tickets, and watch one of them reach a merged pull request this week. The lessons will still be here when you have questions.
or see how managed Teams work