For tech leads

Add an agent squad to your team's backlog — under your review rules.

Point ampm at the issues your team never gets to. Agents read your AGENTS.md, follow your conventions, and open pull requests that go through the same review and CI as everyone else's. You lead the work; nothing merges unless you want it to.

Join the wait listTry the demo

A kanban board with four lanes — Ideating, Planning, Building and Shipping — carrying tasks from a fresh idea through to a pull request waiting for review.

Fits your team

A squad that works the way your team already does

Issues in, pull requests out

New GitHub issues on a connected repo become cards, and ampm reports progress back on the issue so your team sees it where they already look.

Your review, your CI

Every change is a normal pull request: your branch protection, your required checks, your reviewers' comments sent back to the builder.

Across your services

One workspace spans the services the squad changes, with shared libraries and API specs added as read-only context — so a change that crosses services is planned as one.

Every decision on the record

Plans, review rounds and full transcripts stay with each task, so a teammate can audit any change without asking anyone.

Ships the way you ship

Merged work follows your release process — the deploy step reads your repo's instructions, not a generic script.

The lifecycle

The process you'd want from a new hire, from day one

Plan before you build, test and review before you merge, release the way the team releases. It's the discipline of the best Silicon Valley engineering orgs, distilled from fifteen years inside them — applied to every task without a reminder.

  1. Planning
    your call
  2. Implementing
     
  3. Testing
     
  4. Reviewing code
     
  5. Merging
    your call
  6. Releasing
     
  7. Done
     

Have a poke around

Your team's backlog, moving

Invented data, real mechanics. The reviewer stops to ask before removing an endpoint a partner still calls — with your repo's own rule as evidence — and the flaky test starts on its own when there's room.

Scroll a little further to load the demo

The board

Every piece of work, at the exact stage it's in. Positions aren't decoration — a card's column IS its state.

The inbox

One queue of everything blocked on you, each ask carrying the plan, the diff and the transcript behind it.

Activity

Who's working right now, on what, and what each run cost — live, with every finished run still on the record.

Have a poke around

Sev-1? The line stops.

Incident response is built in: a P0 halts every in-flight run so all capacity goes to the fix, which ships through your normal review and deploy — then the queue resumes, nothing lost.

Scroll a little further to load the demo

Engineer from anywhere

Paged at 2 AM, handled from your phone

An incident doesn't wait for your laptop. File the fix from your phone, pause what's live, and approve the hotfix merge — the squad keeps its rules even when you're away from the desk.

From a beach chair

Scroll a little further to load the demo

Signals from the outside world

Sentry spikes and flaky tests become tasks

Intake processes watch production errors and CI on main, find the commit that broke it or the test that flakes, and suggest a fix ticket with the evidence. Triage becomes a yes/no.

Intake2 processes on · receiving signals

Processes

Production errorsSentry · payments-service · Every 15 minutesOn
  1. Keep new or spiking errors
  2. →Find the commit that introduced it
  3. →Suggest tasks
    Flaky tests on mainGitHub Actions · main · NightlyOn
    1. Keep tests that failed then passed
    2. →Rank by how often they flake
    3. →Suggest tasks

      Suggested tasks

      Suggestions arrive once signals come in.

      Roadmap

      Sent tasks land here.

      Your rules

      It reads your repo's rules. Then it follows them.

      The AGENTS.md you already keep is the whole onboarding pack: your architecture, your code style, how this repo actually ships, the way you like commits and pull requests written. Every agent is told your guidance outranks generic best practice — and each one reads it for its own job. The builder picks up your idioms and your commit conventions. QA finds out how this repo verifies a change and runs that, not some invented checklist. The seat that ships knows what “shipped” means around here.

      And when an agent needs a rule you never wrote down, it doesn't guess and it doesn't wing it. It does its best, flags the gap, and walks you through writing it down — so the factory keeps a running picture of what your repo expects, and every seat gets more personal to your codebase the longer it runs. Want one to behave differently? A stricter reviewer, a builder with house rules? That's a markdown file in .ampm/, checked in and reviewed like any other code.

      your-repo/

      AGENTS.mdEvery seat defers to it
      ## Conventions
- Money is integer cents, never floats.
- Every API change updates openapi.yaml.
- Commits follow Conventional Commits.

      Every agent reads it first

      PlannerBuilderReviewerTester

      Questions

      Does it follow our conventions?

      Yes. Every agent reads your AGENTS.md, CLAUDE.md and docs, and your guidance outranks generic best practice. Repo-specific reviewer and builder rules live in .ampm/.

      Does it bypass branch protection?

      Never. Changes are normal pull requests through your required checks and reviewers.

      Which coding agents does ampm work with?

      Claude Code and Codex. ampm runs them on the subscription you already pay for — no API keys and no second bill for tokens — and when one account hits its usage limit, work moves to a backup account without losing anything.

      Does ampm merge code on its own?

      Nothing merges unless you want it to. Plans, questions and merges wait in your inbox with the plan, diff, pull request and full transcript attached, and you decide which decisions to keep and which to hand off.

      Where does the code run, and is my repo safe?

      Every task runs in an isolated sandbox on its own worktree, on workers you choose — your laptop, a server you own, or a cloud machine — and can only push to a branch. The output is always a pull request into your repo.

      How is this different from chatting with a coding agent?

      A chat forgets everything when you close the tab and needs you watching it. ampm keeps every task in a database with its plan and history, runs a real process — plan, implement, test, review, merge — and only asks you when a decision is actually yours.

      Can one workspace cover several repos?

      Yes. Add the repos agents should change, and add more as read-only context — a design system, an API they call, product docs — so their work matches what's around it. One change can span several repos as one piece of work.

      How do I get access?

      Join the wait list with Google or GitHub. We're letting people in a few at a time, in the order they joined, and we'll email you when it's your turn.

      Early access

      Give your team more hands

      We're letting people in a few at a time. Join the wait list with Google or GitHub and we'll email you when it's your turn. Run it on our cloud or on infrastructure you control — your repos, your subscriptions, workers on machines you choose.

      Join the wait list