Autonomous Remediation

Two Runs, Inverted Polarity

On 2 June 2026, Roxabi's agent factory turned its own multi-agent machinery on its own codebase. A quality audit had already swept the repository — 69 agents across 20 waves, eight domains, 3,291 files — and distilled 1,258 raw issues into 22 actionable findings. This is the report of what came next: paying those 22 findings down, end to end, with no human gate between an issue and its merge.

The audit and the remediation are the same shape run in opposite directions. The audit was a read fan-out: many agents looking, nothing changing. The remediation was a write fan-out followed by a serialized merge: many agents changing, one branch absorbing. Same machinery, inverted polarity.

From Audit to Epic

The remediation did not start from a hunch — it started from a plan, and the plan was machine-built the night before. The word “audit” covers two different instruments here, and they should not be confused.

The scanner is the standing pulse — cheap, deterministic, always on. The deep pass is the diagnosis. It ran overnight as a read-only fan-out — many agents reading, none writing — partitioning 3,291 files across eight analysis domains in twenty waves, driven by Kimi: a low-cost, long-context model routed through the LiteLLM proxy, which is what makes a 69-agent sweep affordable to run while you sleep. It surfaced 1,258 raw issues, ranked them P0–P3, and synthesised them into a committed manifest and eight domain reports. That read half has its own write-up — the companion Multi-Agent Audit — and its method is a reusable artefact, the audit playbook.

A pile of 1,258 issues is not a plan. So Opus took the highest-severity findings — the P0 and P1 issues — and did the work that turns symptoms into a plan: it derived the root causes behind them. Not “fix these two hundred lines”, but “these are the handful of structural causes those lines share”.

Those root causes became epic #1662 — 22 actionable findings. The epic was decomposed into leaf tasks, and the leaves were wired together with native GitHub blocked_by edges into a dependency graph: where two fixes touched the same file, one was marked blocked by the other; where footprints were disjoint, no edge. That graph is the schedule.

The Harness

The schedule is data; the harness is the engine that executes it. epic-1662-wave.mjs is a Workflow script — deterministic JavaScript control flow (loops, fan-out, conditionals) wrapped around model-driven agent() calls. Each invocation runs exactly one dependency-wave of leaves and, deliberately, does not merge — merging is the main loop's job. That split is what lets each wave's dependents branch from an already-merged base.

Inside, every leaf runs the same pipeline, adapted to its size.

• Implement. A small leaf gets one implementation agent in an isolated git worktree. A large one is first decomposed by a PLAN agent into disjoint file-groups, implemented by parallel sub-agents (no two touch the same file, so the merge is conflict-free by construction), then stitched together by an INTEGRATE agent. Either way it ends in a PR carrying a decision trace.
• Review. Five lenses read the diff in parallel — correctness, axial architecture, security, tests, and rules-compliance — each a specialist agent. Only blocking and major findings advance.
• Validate. Every advancing finding faces two skeptics, each prompted to refute it by default. A finding survives only if confirmed — plausible-but-wrong review noise dies here.
• Fix & defer. A fixer applies the confirmed findings, re-runs the gates, and pushes. The loop runs at most twice; anything still unresolved is filed as a deferred sibling issue, blocked by the original — the batch never stalls on a stubborn finding.

The shape is small enough to read in one screen — a parallel review panel, then a per-finding skeptic vote:

// 5 lenses read the diff in parallel — each a specialist agent
const reviews = await parallel(LENSES.map((L) => () =>
  agent(reviewPrompt(n, L, diff), { agentType: L.agent, schema: FINDINGS_SCHEMA })))

// keep blocking/major, then refute each finding with 2 skeptics
const verdicts = await parallel(findings.map((f) => () =>
  parallel([1, 2].map((k) => () =>
    agent(validatePrompt(n, f, diff, k), { schema: VERDICT_SCHEMA })))
    .then((votes) => ({ f, real: votes.some((v) => v.real) }))))

const confirmed = verdicts.filter((v) => v.real).map((v) => v.f)

Four properties hold for every agent in the run, by construction:

• Typed output, never prose. Every agent is forced to emit a structured result against a JSON schema — the failure mode “agent ended in a paragraph instead of a result” is designed out.
• One contract, injected verbatim. The same RCA rules (§6) go into every prompt, so nineteen uncoordinated agents reason the same way.
• Retry at the inference level. A tryAgent wrapper retries three times with escalating back-off — the fix for the opening-night overload storm, now a default.
• Isolate, defer, continue. A leaf that throws is caught, recorded, and skipped; the wave never aborts on one failure. Concurrency is capped at three issues in flight, for merge cadence.

From Reviewed PR to Merged

The workflow hands back a reviewed PR; the main loop takes it from there — and this is where it stays autonomous. The split matters: the workflow develops, the main loop merges, so dependents always branch from a freshly-merged base.

Scheduling by Footprint

Nineteen leaves cannot all run at once — some touch the same files, and two agents editing one file produce a merge conflict, not a feature. The scheduler used a single predicate, read straight off the epic's blocked_by graph: disjoint footprint ⇒ parallel; shared file ⇒ serial. Parallelism was capped at three concurrent agents, and authorized only where footprints were provably disjoint.

One Contract, Nineteen Agents

Nineteen agents worked in isolation, none aware of the others. What kept their output consistent — and reviewable — was a single reasoning contract, injected verbatim into every implementation agent and echoed into every PR body.

obs(finding)  →  root_cause              # not the symptom
              →  corrections ∈ {Patch ⊻ Archi}   # choose, explicitly
              →  fix at the level of the cause
              →  trust(input)?  ·  tested ∧ correct   # green ≠ correct
              →  trace the decision in the PR body

The rule that did the most work was green ≠ correct: a passing CI run is necessary, never sufficient. And forcing every agent to choose between a patch (treat the symptom) and an architectural fix (move the cause) — out loud, in the PR — turned nineteen uncoordinated runs into an auditable record. This document is writable because that record exists.

What Broke, and Why

The value of a retrospective is in the failures. Seven blockers stalled the run; each was traced to a root cause and fixed at that level, not patched over. The expensive ones were systemic — and now live as hardened defaults in the orchestration harness.

The Cost, Honestly

Time is hard data, read straight off PR timestamps. Tokens are not — the harness never captured per-agent usage, so the run total is a bottom-up estimate: count the agents the pipeline actually spawns, multiply by what one agent costs. It is labelled as an estimate, but the order of magnitude is not in doubt.

How many agents per issue?

The run was never thirty agents — that was the count of top-level /dev invocations. The real fan-out is the per-issue pipeline (§4) spawning a fresh sub-agent at every step, and the heavy steps fanning out again. Read straight off epic-1662-wave.mjs:

A representative small leaf, single review round, ~3 findings: 2 + 5 + 6 + 1 ≈ 14 agents. A second round nearly doubles the review/validate/fix block, pushing a contested leaf toward ~25. Blended across the nineteen merged leaves (mostly small, four large), call it ~18 agents per issue → ~340 agent invocations for the run.

Plus debug. The opening overload storm (§7) spawned a full wave that died on first inference — 9 agents, ≈ 0 tokens each (the API 529 hit before any real work), so it cost wall-clock and a re-run, not tokens. Add a handful of re-devs and the #1697 stale-base hand-recovery on top.

Tokens, estimated

A live dev, review, or fix agent reads its slice of the repo, the PR diff, and runs the full gate suite — that lands a single agent at 100–200k tokens, sometimes more. The one hard datapoint sits at the low end of that band, exactly as expected: the two instrumented agents were post-compaction recovery runs, resumed from a shrunk context. So ~340 agents × ~150k ≈ ~50M tokens for the run — a ~35–70M band at the 100–200k bounds — and ~2.5–3M tokens per issue. The earlier “~1.5–2.5M for the whole run” guess was off by ~20×: it was roughly the cost of a single issue.

Proof It Landed

Nineteen merged PRs prove the process finished. They do not prove the code is right — a green pipeline and a closed epic can both sit on top of a fix that quietly drifted from its intent. So once the run was done, a second-layer audit read the merged staging source directly, finding by finding, asking one question: did each fix actually land the way its PR claimed?

Three specialist agents split the surface — refactors and architecture, the security-sensitive paths, and cross-layer drift — and read the files, not the diffs.

The two architectural leaks were real but small — hub-core code still discriminating two platform-specific message types where a generic trait belongs, and an error classifier keying off adapter module names instead of a taxonomy the adapters register. Add one hardcoded limit that wants a name, and that was the whole residue: filed as non-blocking follow-ups, on the record rather than buried.

What Compounds

The findings were specific to one codebase. The patterns are not — these are the parts that carry to the next run.

• Leaves over umbrellas. Schedule on the actionable leaf; let parent issues auto-close when their children merge. No phantom dependencies.
• Footprint-based parallelism. “Disjoint footprint ⇒ parallel; shared file ⇒ serial” is a cleaner predicate for conflict avoidance than issue size or priority.
• Decision-trace PR bodies. Root cause + Patch ⊻ Archi + level, in every PR. It makes independent agents auditable — and a retrospective writable.
• Isolate, defer, continue. A failed leaf is isolated and deferred; the wave moves on. No single failure stalls the batch.
• Baseline-grandfather for debt gates. A new gate ships blocking new violations while grandfathering the existing ones, with a burn-down to follow — so the gate lands today instead of waiting on a 90-item refactor.

Sources & Code

Every artefact in this report is public. The repository is Roxabi/roxabi-factory (AGPL-3.0).