What is YAGNI and how does it work?

What does YAGNI actually do?

YAGNI runs agent Teams, and it introduces them the way your org already introduces people. A Team mirrors one of your engineering teams, never a repository. It works on the repositories you attach, from the tickets you choose, under the Playbook it has learned, with one accountable person. Named Agents serve on it, and every piece of work is credited to the Agent that did it on the Team it served.

That is the whole mechanism: ownership, review, and a record. The thing it is built against is the unmanaged agent, the pilot that impresses for an afternoon and then decays into babysitting because nothing ever put it on the hook.

Who does the work?

Six named Agents, in the order the work moves. Bailey, the Product Manager, proposes the next ticket off your backlog and never ships. Reeve, the Staff Engineer, reads the plan before a line is written and never authors or blocks it. Wright, the Builder, plans an accepted ticket and takes the approved plan to a draft pull request, and never merges. Proctor, the Reviewer, reads the pull request through its checks and posts one review. Fletcher, in beta, boots the app in a sandbox and walks the change in a browser, and never edits code. Harper reports what happened and never acts. Each one is covered in the Agents lesson.

What is a ticket, and which clicks are yours?

A ticket is one piece of engineering work moving through six stages: Proposed, Plan, Build, Review, QA, Done. Done means merged. Its record is the case file: the proposal, the approved plan, the runs, the pull request, the review, the browser evidence, the decisions a person answered, and what it cost. Every decision the ticket needs resolves there, in the footer of that one page.

On a supervised Team, three of the clicks are yours. Accept the proposal, or start the ticket yourself. Approve the plan. Merge the pull request. Your first ticket walks one from your tracker to the merge.

How much does a Team do on its own?

Exactly what you have set, line by line. A Team is one sentence of scope plus one line per thing an Agent does here, and each line carries its Authority inside it: “Bailey proposes from the backlog every weekday at 9, supervised by Priya.” “Reeve reads plans before they are built, autonomous.”

The Ladder has two rungs, supervised and autonomous, set per line. A supervised act waits as a gate addressed to a named person. An autonomous act runs and leaves a Receipt. You move a line up with one explicit act, with its track record beside you, and nothing moves a rung on its own. One floor never moves: merge is always a person’s click.

Where do you start?

On Work, the first screen after you sign in. With nothing connected yet it offers two doors: connect GitHub, or install YAGNI Code. Through the first door you create a Team at one of three sizes: your own tickets, a backlog, or pull request reviews. They are the same Team, differing only in whose tickets it works from and which lines are on, and growing one is adding a line. The whole path is a few minutes. If you would rather walk it with us, book 30 minutes.

Where do you work from?

Wherever your people already are. The web app carries Work, the case file, Decisions, Agents, Usage, and the Team page, for the person who manages. YAGNI Code is the desktop app and the CLI your engineers run by hand. An org with a harness it loves can manage Teams from Claude Code or Codex over the YAGNI MCP server. And Slack carries the gates and the Daily Brief to the people who never open a new tool. One record, one set of gates, all four ways in. Everything runs on vetted, US-hosted open weight models at 60% or more under comparable frontier API rates, on one rate card for your developers and your Agents alike.