The Autonomous Overnight Run

March 2026. Eleven projects across the organization. Ten parallel agents dispatched at approximately midnight.

By 3am, the run was complete. Thirty-six P0s fixed. Forty-seven P1s fixed. Eighteen P2s fixed. Nineteen PRs open for review. Knox reviewed them in the morning over coffee.

This is not science fiction. It is a specific architecture with specific rules. The architecture is reproducible. The rules exist because the first run produced failures alongside its wins — and each failure generated a constraint that made the next run cleaner.

What Made It Autonomous

The word "autonomous" is doing real work here. Parallel is not autonomous. Ten agents running simultaneously but all needing human decisions is just a faster version of manual work. Autonomous means the agents ran from start to PR without a single mid-session question.

Five properties made that possible:

1. Structured audit documents as input. Each project had a code-audits/<project>/MASTER-SUMMARY.md with findings sorted by severity. Agents received a clear punch list with priority, location, and description — not "review and improve the codebase." Ambiguous input produces ambiguous output.

2. P0 → P1 → P2 cascade. Every agent fixed all P0s first. Most completed P1s. Some reached P2s. The cascade guarantees that even a partial run produces maximum value — the most dangerous bugs are fixed before any agent runs out of time.

3. One agent per project. No two agents occupied the same repo simultaneously. Parallelism runs across projects, never within them. Shared repos produce merge conflicts, race conditions on test state, and contradictory fixes.

4. Pre-flight test validation. Every agent ran the full test suite before opening a PR. A PR that fails CI on creation is not a finished artifact — it is a task handed back to Knox. Pre-flight validation means the PR is ready to review, not ready to debug.

5. Verify-before-fix discipline. Every agent confirmed each finding with a grep before writing a fix. This caught the false positive rate before it became merged broken code.

The Input Format That Works

The MASTER-SUMMARY.md structure that produced clean agent execution:

# Project: sports-prediction-agent
## P0 — Fix immediately
- [TR-01] DRY_RUN flag trap: live_trading=True bypassed by dry_run=True check
- [TR-02] th_bets not persisted — duplicate bets on restart

## P1 — Fix this session
- [IN-01] Heartbeat monitors wrong table (bets vs sports_bets)
- [MO-01] fetch_ohlcv returns [] on all errors — silent degradation

## P2 — Fix if time allows
- [TE-01] 12 test stubs never implemented — missing coverage
- [CO-01] Hardcoded timeout values — should be configurable

Each entry has: a reference ID, a description of the problem, and enough context that the agent knows what to look for. It does not have a proposed fix — that is the agent's job. It has a clear problem statement.

The agent prompt structure that consumed this format:

You are fixing code in the <project> repository.
Your task definition is in code-audits/<project>/MASTER-SUMMARY.md.
Fix all P0s. Fix as many P1s as time allows. Fix P2s only after P1s are complete.
Before fixing any finding, verify it exists with a grep command.
Run the full test suite before creating a PR.
Create a single PR with all fixes. Do not split by severity.

Six sentences. No ambiguity about scope, order, verification, or output format.

What Failed and the Rules It Produced

Rule: Mock all external state in tests. Never read real SQLite or real filesystem paths in a test environment. Tests must be environment-agnostic.

Rule: Single PR per project, always. The prompt must say "single PR" explicitly. Agents default to logical groupings without this constraint.

Rule: Estimate token cost before dispatching. Set a budget ceiling. At Sonnet pricing, 11 repos × ~100K tokens each is real money. Unbudgeted runs are uncontrolled cost centers.

Rule: Structure agent prompts to submit the PR then end the session. Poll CI in a separate pass. The agent's job ends at the open PR — CI review is a human or orchestration task.

When to Use This Pattern

Autonomous overnight runs work when four conditions are true:

1. You have structured audit documents — real punch lists, not vague improvement notes
2. Fixes are isolated per project — no cross-project dependencies in scope
3. The test suite is passing before the run starts — agents fix bugs, they do not fix broken foundations
4. Pre-flight test validation is in the prompt — CI green before PR creation is non-negotiable

Interactive debugging is the right tool for: systems in unknown state, cross-project coordination, architecture questions, and anything where the fix requires a judgment call about product behavior. The overnight run handles everything else.

The Bottleneck Is Audit Quality

The agents performed in direct proportion to the quality of the MASTER-SUMMARY.md they received.

Projects with clear, located, severity-ranked findings produced single-PR clean fixes. Projects with vague findings produced questions, missed scope, and PRs that needed significant rework. The agents were not the variable. The input was.

A structured MASTER-SUMMARY.md is not overhead. It is the difference between autonomous execution and supervised execution. Build the audit document with precision and the overnight run runs itself. Build it with ambiguity and you are not sleeping — you are just not watching.

The Numbers

Eleven projects. Ten agents. Three hours. Approximately 100 bugs fixed. Nineteen PRs. One morning review session.

The ROI on structured audit documents is not marginal. It is the entire reason the run worked.