# What is Automaintainer

Automaintainer (AM) is **the autonomous improvement platform** for your code
repositories. You point it at a repo, give it a bounded objective (or pick a
playbook), and a **fleet of AI agents** plans, implements, **verifies**, fixes,
and opens a merge‑ready pull request — on a schedule, on **your own provider
keys**, with no human in the per‑step loop.

The wedge is **maintenance, not feature autopilot**. The reliable unit of work
is a *well‑scoped, verifiable objective* — keep tests green, raise coverage,
bump dependencies safely, fix lint, harden error handling, keep docs in sync —
never an open‑ended PRD. AM wins on **trust and cadence**.

## What makes it different

- **Verified, not vibes.** Every change runs the [Verification Gate](/docs/verification-gate)
  (build → test → fix → re‑verify) before it can become a PR. *Done = verified,
  not just written.*
- **A fleet, not a bot.** Specialised agents (architect, dev, QA) coordinate over
  a peer message bus, across one or many [workers](/docs/add-worker).
- **Autonomy you grant.** The [trust ladder](/docs/trust-and-plans) goes from
  review‑only to auto‑merge — your call, per plan.
- **Your keys, your models.** [BYOK](/docs/byok-provider-keys), harness‑agnostic
  (claude / opencode / pi / tau). No lock‑in.
- **It gets better every run.** Per‑repo [memory](/docs/memory) accumulates
  lessons, and an optional [objective ledger](/docs/objectives) tracks cumulative
  progress toward a goal across runs — so a campaign builds instead of restarting.
- **It works your backlog.** AM can [solve your GitHub issues](/docs/issue-solving)
  and [verify incoming pull requests](/docs/pr-watcher) — not just scheduled focuses.

## How a run flows

1. A trigger fires (manual, [scheduled](/docs/scheduling), or [explore mode](/docs/explore-mode)).
2. AM prepares an isolated worktree on a [worker](/docs/add-worker) and spawns the
   [team](/docs/teams-and-models).
3. Agents implement the [focus](/docs/focus) and commit.
4. The [Verification Gate](/docs/verification-gate) runs; on failure AM fixes and
   re‑verifies.
5. An objective‑adherence check confirms the change actually addresses the
   [objective](/docs/objectives); off‑objective work is flagged, not auto‑merged.
6. A pull request opens — merge‑ready, or a draft if the gate stays red.
7. Depending on your plan, AM reviews and/or [auto‑merges](/docs/auto-merge).

## Next steps

- New here? Start with the [Quickstart](/docs/quickstart).
- Want the mental model first? Read [How it works](/docs/how-it-works).
- Evaluating? See [Trust ladder & plans](/docs/trust-and-plans) and
  [Security & data](/docs/security).