AI Agents

Background agents that work alongside you while you code — a second set of eyes that reviews, plans, and keeps your project honest. Each agent is opt-in and runs per project.

The first agent is live today: the Product Owner. Solution Architect, Team Lead, and QA agents are on the way.

The Product Owner (PO) is a senior product reviewer that runs after each AI turn. It thinks like a human colleague — it observes, reviews, and assigns work, but it never edits your code directly. When it has something to say, it posts a [PO]: note in the chat.

Enabling the PO on a project

The PO is off by default and its setting is stored at the workspace level — turning it on affects only that one project. There are three ways to enable it:

What happens when a turn completes

The PO fires after the model finishes a turn — never during, and never on its own turns. The flow each time:

1. 1

   Guard. Skips immediately if the PO is disabled, the turn was aborted or failed, or the turn was started by the PO itself. One run per turn — no ping-pong.

2. 2

   Gather facts. Runs git status / git diff to see what changed, and checks for open gaps.

3. 3

   Cold start? On the very first turn of a fresh project, the PO gathers context and asks you a few clarifying questions instead of guessing — then it's done for that turn.

4. 4

   Pick a mode. Files changed → Mode 1. No files but open gaps → Mode 2. Nothing left → Mode 3 (see below).

5. 5

   Act. Post a [PO]: note, optionally commit (Mode 1), and — in active mode — inject the next directive so the model picks it up on the following turn.

The three decision modes

Passive vs. active

Passive (the default) posts a[PO]: note you can read and act on. Activegoes a step further — it injects the PO's next-step directive into the conversation so the model acts on it automatically. Mode 3's approval gate is always respected, in both behaviours.

Operation layers (advanced)

Layers control how the PO runs and are orthogonal to the modes. Drop a .po/operation.json file in your project root:

{
  "op": "autonomous",
  "since": "2026-06-13T10:00:00Z"
}

• chat-replay — continue the most recent unaddressed [PO]: chain instead of starting new work.
• autonomous — keep going without per-turn confirmations. (Mode 3's approval gate still applies — autonomous halts when it fires.)
• directive — run a saved instruction as a one-shot imperative.

Set { "op": null } to abort any running operation. Directives older than 7 days expire automatically.

Safety gates

Before any auto-commit, the PO scans the staged diff for secrets (Anthropic / AWS / GitHub / Google / Slack keys, private keys) and refuses to commit off-limits paths (.env, credentials.*, *.pem, key files, and more). Commits use a per-command identity (MR CODER PO <[email protected]>) so your global git config is never modified.

Command reference

How the PO compares

Most AI coding tools review code only when you ask, and return free-form notes. The Product Owner runs a structured governance pass after every turn — with a phase-gate pipeline, persistent registers, and an approval gate no single-prompt reviewer offers.

Comparison reflects each tool's built-in review capabilities as of June 2026. Competitor features may be achievable through manual prompting or third-party plugins.

More agents, coming soon

The PO is the first of a team. Each new agent plugs into the same per-turn loop and the same Agents panel — opt-in, per project:

• Solution Architect (SA) — reviews design decisions, system structure, and architectural trade-offs.
• Team Lead (TL) — coordinates work across agents and keeps it moving toward the goal.
• QA Engineer (QA) — checks test coverage, validates behaviour, and hunts regressions.

Works with every AI provider

The PO is provider-agnostic — it runs the same review after every turn, regardless of which backend handled the work. The Claude provider uses the Agent SDK's injectUserMessage()mid-turn channel for active-mode directives; the CLI providers (Kilo Code, iFlow, Qwen) use interrupt-and-continue — abort the running subprocess, preserve the partial response, then fall through to a fresh spawn with context replay.

All PO state lives on disk (workspace .mrcoder/po/ + global ~/.mrcoder/), so a workspace migration does not lose project memory. Settings live under the mrMultiCoder.* namespace.

Multi-message acceptance

The PO is built to never reject a new message. If you press Send while a turn is still generating, your message is accepted immediately — the PO either injects it into the live turn (Claude) or interrupts the running subprocess and continues with your new message (CLI providers). There is no pending queue, no "wait for the current turn" notice, and no rejected send. Partial responses from interrupted turns stay visible in the chat history.

Stuck-loop watchdog (active mode)

Active mode has no fixed turn cap — the PO loops continuously until project closure (status.complete: true). The only halt is the stuck-loop watchdog: after 3 consecutive PO-initiated turns with no new action delivered to the model, the PO pauses with a visible notice:

The watchdog uses per-turn action-signature dedup — a fresh developer-action ID counts as progress, while repeated IDs (a model that just re-acknowledges the same directive) are treated as no progress. Type a message or run /po disable to reset.

14-phase governance pipeline

GREEN STATUS is gated by a 14-phase pipeline. The PO refuses to sign off a project as production-ready until every gate passes; GREEN claims without evidence are refused by the anti-rubber-stamp gate:

• Phase 0 — Prerequisites clean repo state.
• Phase 0.5 — Requirements Ingestion reads project docs and drafts requirements.md + feature-tree.md.
• Phases 1-9 — current-task verification, regression, deep logic review, architecture, security, operational, static analysis, validation.
• Phase 10 — root-cause analysis on every issue.
• Phase 11 — Product Ownership Review.
• Phase 11.5 — End-User UX Verification (live UI walkthrough, enterprise checklist).
• Phase 11.6 — Per-Control UX Coverage (Playwright visits every control + screenshot + vision verdict).
• Phase 11.7 — Control Coverage Recovery (kill switch + rollback runbook for false-positive stalls).
• Phase 12 — Release Readiness Review.
• Phases 13-14 — Post-GREEN Competitive Intelligence + Innovation & Continuous Improvement.

Per-control coverage gate (Phase 11.6)

GREEN is blocked unless every interactive control on every surface is exercised by a Playwright test, has a fresh screenshot, and passes a vision regression check. The inventory is scanner-derived (deterministic, no AI); the per-control spec is AI-authored but verified end-to-end with screenshots. A GREEN claim with missing coverage is refused with kind: control-coverage-gap — the PO cannot claim coverage it did not actually verify.

Vision verification per screenshot

Every per-control screenshot is fed to a vision model that checks for visual regressions (broken layouts, missing labels, contrast issues). Verdicts are persisted to .mrcoder/po/control-vision-verdicts.json — a status: regression verdict blocks GREEN. When ANTHROPIC_API_KEY is not set, the gate runs in dry-run mode and returns inconclusive (safe default).

Research gate (Phase 11.5 enforcement)

Mode 3 (competitive research / improvement proposals) is locked until the PO has run a passing end-user UX review AND seen a fresh verification report. When research is locked, the PO runs a pre-research verification turn instead — so the product is correct and production-ready BEFORE the PO spends a turn researching enhancements.

Decision & technical-debt registries

Every accepted risk, tradeoff, and exception is recorded in .mrcoder/po/decision-registry.md with Decision / Date / Reason / Impact / Approval Rationale. Accepted decisions are not re-raised unless requirements change, new evidence emerges, or risk severity increases. The technical-debt register tracks code smells with severity, owner, and acceptance status.

Hard Rules (anti-violation layer)

Hard Rules are extracted from CLAUDE.md on every turn and injected via appendSystemPromptso they prompt-cache. The PO checks them with the same weight as requirements — Hard Rules such as "never name the extension Claude Code" or "do not store any API key in settings.json" are explicitly tested in the verification runner, with critical violations blocking GREEN.

Improvement backlog (Phase 14)

Mode 3 proposals are persisted to .mrcoder/po/backlog/po-actions.json with priority + status (Proposed / Approved / Deferred / Rejected). Approved proposals enter the next-turn active-mode injection queue; deferred proposals carry a reason and a re-review date. The backlog survives reload — you can review past proposals offline.

No third-party CLI auto-install

For CLI-based providers (Kilo Code, iFlow, Qwen), the extension discovers the CLI via which / where. If the CLI is missing, an actionable install hint is shown — the extension never auto-installs a third-party tool on the user's behalf.