# YAGNI: full canonical description

## What YAGNI is

YAGNI runs agent teams, managed like your engineering team. Named agent Workers are engaged onto Teams that mirror an engineering org, carry software work from a backlog ticket to a merged pull request, and earn autonomy on a record anyone can read. Every consequential step is a gate a person answers. Merges and anything irreversible stay with a person at every level.

The name is the software-engineering principle "You Ain't Gonna Need It." The stance is management, not magic: agents fail for lack of management, not intelligence. YAGNI introduces agent Teams the same way an engineering org already manages human teams. Ownership: a Team is on the hook for a scope and reports to one accountable person. Review: a plan a person approves, a review a person can read, gates a person answers. A record: the track record, the decision ledger, the Playbook. The enemy is the unmanaged agent that impresses for an afternoon and decays into babysitting, and the workflow graph that puts a team in its box and has to be maintained by hand. Not a workflow graph. A team.

YAGNI meets an engineering org where it already works: the Teams are managed from the web app, from Claude Code or Codex connected to the YAGNI MCP server, and from Slack. Alongside them, YAGNI Code is a tailored harness of the org's own, a desktop and CLI coding agent that runs 60% or more under comparable frontier API rates, on one rate card for developers and Workers alike.

## The Workers

Six named crafts, in the order a work item meets them. Each has inputs it reads, an artifact it produces, and a ceiling it cannot climb past no matter how good its record gets.

- **Bailey (Product Manager).** Reads the backlog attached to the Team (a Jira project or epic, a Linear project), the Team's Responsibilities, and the decision ledger. Produces a proposal with the evidence it came from and what it is expected to move, a few at a time. Ceiling: Supervised at most; a proposal always lands in a person's queue. Runs weekday mornings or on request.
- **Reeve (Staff Engineer).** Reads the plan, the Team's Playbook, and its watch-set (migrations, auth, new dependencies, data deletion, anything you add). Produces a critique in place: concerns, wording, or a plain no concerns. Advisory only: never authors the plan and never blocks it. Reads best with a role note saying what to watch for on this Team. Runs on the strongest reasoning model.
- **Wright (Builder).** Reads the approved plan, the repository in a cloud sandbox, and the ledger. Produces commits and tests on a branch, a draft pull request, and answers to review rounds up to the cap you set. Ceiling: the pull request is the finish line (a draft one at Training); merging stays with a person.
- **Proctor (Reviewer).** Reads every pull request on the repositories the Team attaches, through its checks: deep review, business fit, database, security, tests, complexity, and any check you add. Produces one review, with what it discarded readable behind it, then follow-ups on new commits until the PR is clean. Never blocks a merge; approves once the Engagement reaches Supervised, with each approval landing in a person's review queue until Autonomous. Reads the whole repository, not a diff, at a fraction of what a frontier-model reviewer costs.
- **Fletcher (QA, beta).** Reads the exact PR 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, then bounded browser exploration, with screenshots, video, and a verdict on the PR. Never changes application code, never weakens a test, never publishes findings without a Decision.
- **Harper (Chronicler).** Reads the Team's work items and their receipts, plus the channels the Team reports to. Produces the Brief each weekday morning, the standup in Slack, and release notes on request. Reports only; never acts.

## The Team, the Engagement, the Ladder

A **Team** mirrors one of the customer's engineering teams, never a repository. It holds the Responsibilities (the editable statement of what it is on the hook for), the repositories and backlog attached to it, the Playbook it has learned, its budget and guardrails, and one accountable person. A customer runs a Frontend Team and a Backend Team side by side, each in its own cloud sandbox, working in parallel on shared services without colliding. A Team is created by naming it and describing the outcome in plain words; YAGNI drafts the Responsibilities for a person to edit. A Team's privacy setting (shared, restricted, private) governs who sees it and its record.

A Worker serves a Team through an **Engagement**, always the same triple: Cadence (when its work starts here), Authority (what it may do alone here), and Brief (what it knows here: checks, repo scope, scoped Playbook rules). The same Worker can carry different Authority on different Teams: Proctor may approve on the web app and only advise on the infrastructure repository. Settings inherit platform to workspace to Team, and an override always says "set here." Caps per Worker and per day, items in flight, and review rounds are set on the Team, where the review norms actually live.

Every Engagement starts at **Training** and climbs the **Ladder** on its track record: Training (every step waits for a person), Supervised (reversible work proceeds with a visible stop window), Autonomous (a person reviews outcomes). The track record shows proposals accepted unedited, plans approved, PRs merged, reviews acted on, and the misses. Promotion is a button a person presses when the record supports it, never a switch that flips itself. Demotion is a button too, and reversing something an Engagement shipped on its own lowers it one rung automatically, on the record. The floor is permanent: merges, deploys, and anything irreversible stay gated at every rung, forever.

## The work item and its gates

A **work item** is the record of everything a Team did with one piece of work: the proposal, the approved plan, the runs, the pull request, the review, the test evidence, the gates a person answered, and what it cost. It is one page, the case file, and every decision the item needs resolves on it. Never a second queue.

The lifecycle has seven steps and four gates. Proposal (Bailey pulls it from the backlog with evidence; a product manager can be tagged in Slack for the business read) and the gate: accept the proposal. Plan (Wright drafts it in a sandbox with the questions it could not answer from the ledger surfaced for a person; Reeve critiques it in place) and the gate: approve the plan. Build (Wright: commits, tests, and a draft pull request on a branch; nothing touches the trunk). Review (Proctor posts one review through its checks; Wright answers each finding until the PR is clean, up to the rounds you allow). Verify (Fletcher boots the app in the Team's sandbox, walks a test plan in a browser, attaches the video) and the gate: unblock, if it needs something only a person has. Result (a person reads the PR with everything attached, merges or sends it back) and the gate: accept the result. Report (Harper's standup and Brief say what shipped, with the receipts, and what still needs a person).

Comments on the case file are not side conversation. A product manager's answer at the proposal becomes a line in the plan. An engineer's correction on the plan becomes a Playbook rule if it should. Domain knowledge goes in at the front, not in a review comment at the end.

## The system of context

Every plan a Team writes, every question a person answers, and every decision behind a merge lands in one shared record: the decision ledger. The next plan reads it first, so the Team stops re-deciding what the customer already settled, and engineers read it instead of asking around. Plans and decisions are shared across the workspace; the Playbook is the Team's own.

The **Playbook** is where judgment becomes rules. A domain expert writes a business rule in plain words ("price a claim as the contracted rate times the modifier, minus the member's remaining deductible; never estimate it"). An engineer writes a guardrail ("any migration that adds a lookup needs an index in the same PR"). When decisions show a pattern, the Team proposes the rule, and it is active until a person adopts or dismisses it inline in Settings. Rules can be repo- and path-scoped. Nobody tunes prompts. Corrections take effect immediately; nothing waits for a retraining cycle.

Plans, decisions, and Playbook rules export to Confluence or Drive on request. The system of context is the customer's record, not a lock-in.

## When a Worker gets it wrong

It will. The product is built to make that cheap. Every step on the case file links to the run that produced it: the model calls, the files it touched, what it read from the ledger, what it cost. Proctor's dismissed findings are one click behind the review, with the reason, so a quiet review is checkable. A correction on the case file, in the PR, or in the Slack thread lands in the item now, and the Team proposes it as a Playbook rule if it should outlive the item. A provider outage or a flaky sandbox is a retry button; the run resumes from the last settled step. Lowering a rung is a button. The @yagni rail beside the case file knows the item, the Team, and the ledger, and answers why a Worker did what it did.

## Where you work from

1. **The web app.** Front (where the engineering org stands; orients and never acts), Work (the queue and the record, by Team lane, with the case file as the detail), Projects (commissioned, milestoned initiatives above Work), the Workers directory, Library (shared docs and the decision ledger), Settings, and Usage (spend per developer and per Worker on the one rate card, with the frontier benchmark alongside). For the person who manages.
2. **YAGNI Code.** The coding agent engineers run by hand, day to day, as a macOS desktop app (Apple Silicon, macOS 13 or later) or a CLI (`npm install -g @yagni-app/code`, `yagni login`, `yagni`; runs anywhere Node 22 or newer runs). The developer drives a plan, implement, review rhythm; skills, plugins, and MCPs slot straight in; it runs on the same models and the same meter as the Workers and reads the same decision ledger.
3. **Claude Code or Codex.** Keep the harness you already use and connect it to the YAGNI MCP server: `claude mcp add --transport http yagni-workers https://yagni.app/mcp`, or `codex mcp add yagni-workers --url https://yagni.app/mcp` then `codex mcp login yagni-workers`. From inside the harness: discover Teams, open work, publish a review or adopt an instruction, create a Team when explicitly asked, engage a Worker on demand, request a Reeve critique of a plan or a Proctor review of a PR, and read Fletcher's evidence. Permissions are chosen explicitly at OAuth consent and never exceed the person's YAGNI membership. Separately, when the bill turns to usage rates, `yagni connect claude-code` or `yagni connect codex` routes that harness through YAGNI's models.
4. **Slack.** Bailey tags the product manager at the proposal, Harper posts the standup to the Team's channel, and a reply in the thread lands on the record. The gates come to the people who answer them.

## Start with one gate

Teams that already run their own software factory do not have to replace it. Proctor, Reeve, and Fletcher only check output, never change code, and run beside whatever review the team already has. Engage one on one repository and read its findings next to the incumbent's: when they agree, you know; when they differ, you learn something. The builders join when the record earns it.

## Who YAGNI is for

- **Lean engineering teams** (roughly eight to a few dozen developers) deciding whether to build or buy a software factory, who want a team they can manage rather than a workflow graph they have to maintain, and who want their product managers and domain experts in the loop at the front.
- **Engineering leaders** whose coding-agent bill is turning from flat seats into usage rates, who want the same harness their developers already use on models that cost 60% or more less, with the cost printed per person and per Worker.
- **Teams with a factory already**, who can add one gate beside it and measure.

## Onboarding

Sales-led, by design. On a 30-minute call with the founder, a repository and a backlog are connected (the GitHub App installs workspace-wide with the security lead present), the first Workers are engaged at Training, and the first work item is left waiting at the customer's proposal gate. Engineers keep their harness. Product managers keep Slack. The record starts that day. There is no self-serve funnel and no card required to pilot.

## Pricing

Usage-based, on one rate card with four lanes: Efficient (small bounded steps such as repository maps and routine reads), Standard (proposals, the Brief, everyday code; Bailey and Harper's default), Advanced (plans, builds, whole-repository PR review, browser tests; Wright, Proctor, and Fletcher's default), and Peak (a few tokens of the best reasoning for consequential critiques and hard refactors; Reeve's default). A router places each step on the cheapest lane that holds quality. A developer in the CLI and Proctor reviewing a PR pay the same per-token rates, 60% or more under comparable frontier API pricing, metered per person and per Worker, with every run printing what it cost while it runs. No per-Worker fee, no per-Team fee, no seats, no platform fee; humans are free. Caps per Worker and per day are the customer's to set. No public rate card; the number is scoped on the call (https://yagni.app/book).

## Security & data handling

- **US-only inference, zero data retention:** every model runs on US-hosted providers under zero data retention agreements, with a failover lane that stays in the US.
- **Isolated sandboxes:** each Team's builds and browser tests run in their own cloud sandbox; secrets never leave it.
- **The GitHub App is the only door:** Workers reach repositories through the App installed for the workspace, scoped to the repositories a Team attaches. There is no personal GitHub connection.
- **Workspace-scoped data access:** customer and workspace scope is enforced in application queries and backed by cross-workspace isolation tests.
- **Encrypted connector credentials:** customer-scoped, AES-256-GCM encrypted, resolved only when a tool executes, never placed in model prompts.
- **Identity:** Google single sign-on and Okta today.
- **Attestation:** SOC 2 Type II monitoring window in progress; a DPA and a Business Associate Agreement are available; the trust portal is at https://trust.yagni.app. Security overview: https://yagni.app/security.

## Integrations

YAGNI reads the tools you already pay for and ships approved work back into them. It never hosts your apps or migrates your data. Native connectors today: GitHub (App installation, workspace-wide), Slack, Jira, Confluence, Linear, Google Workspace (Gmail, Calendar, Drive), Notion, HubSpot, Stripe, and Sentry, plus MCP Server, Custom Service, and Database connectors for the tools you run yourself.

## Differentiation

- Against frontier labs' coding agents: those are stateless and single-developer. YAGNI is a team: a shared record, shared rules, and Workers with ceilings, on models that cost a fraction as much.
- Against autonomous-engineering platforms built around a workflow graph: those put a team in the vendor's box and have to be maintained as the models improve. YAGNI is managed like a team: describe the outcome, set the rules, engage the Workers, promote them on the record.
- Against a standalone PR-review bot: Proctor is one Worker on a Team with a Playbook, a track record, and a Ladder, and it can run beside the bot you have.
- Against a build-your-own factory: the Workers, the gates, the case file, the sandboxes, and the exportable record are already built, and nothing about your process has to change to use them.

## Learning YAGNI

The Academy (https://yagni.app/academy) has four courses: Start here (what YAGNI is, the six Workers, your first work item), Set up a Team (Teams, connections, the repository environment, Engagements, Okta), Train, monitor, manage (the Ladder, the Playbook, the Brief and standups, Work and the case file, when a Worker gets it wrong), and Work from your own tools (YAGNI Code, managing Teams from Claude Code or Codex, MCP servers, Datadog telemetry, asking @yagni).

## Useful URLs

- Home: https://yagni.app/
- How agent teams work: https://yagni.app/code
- Pricing: https://yagni.app/pricing
- Book 30 minutes: https://yagni.app/book
- Security: https://yagni.app/security
- Trust portal: https://trust.yagni.app
- Academy: https://yagni.app/academy
- Blog: https://yagni.app/blog