I stopped asking whether each piece worked and started asking whether the pieces worked together. Five coding agents then repaired a notes application in parallel, taking it from 9 tests with 4 failures to 89 passing tests that cross HTTP, the CLI, induced database failure, concurrent writes, and full process restarts. A second repair wave then closed the outer product connections: portable atomic export, same-origin startup, local request hardening, and browser request ordering. The current gate passes 110 Python tests plus 2 JavaScript state tests and a separate real-Chrome acceptance flow.

The experiment produced both a repaired repository and a reusable coordination system for future multi-agent work.

Jennifer Naomi Nguyen · agent orchestration · A method, demonstrated on a generated fixture · September 2026 · built with Claude Code and Codex

Source on GitHub

Starting conditions

Field Notes was a deliberately broken application generated for this exercise, then committed under a neutral handoff identity. That gave the repair a reproducible starting point and known defects to test against; it was not a claim that I rescued an unrelated production system.

What the trace found

We started by mapping the repository and tracing backward from the result a user could see. If the command said it imported a note, where did that note go? Did the running server know about it? Would it still exist after a restart?

That trace found the real problem: several components worked on their own, but the connections between them did not agree. The import command wrote to a private in-memory repository. The server used a different in-memory repository. A successful-looking path could still lose everything when its process ended.

This is the distinction the whole project turns on. A component can pass its own tests while the running application never calls it. The work was not complete when SQLite worked in isolation. It was complete when the real server selected it and a new server process could read the same committed data.

The method

I mapped the running architecture, traced visible outcomes backward to their state owner, and repaired the furthest broken connection first. Five agents worked on distinct boundaries rather than competing over features or files. After integration, an independent verification lane exercised the real HTTP and CLI paths, induced failures, and checked state after restart.

What changed and how I checked it

Five lanes handled architecture and integration, durable storage, atomic import, runtime composition, and independent verification. The verifier did not implement the paths it tested. The first repair made the browser and CLI use one SQLite-backed runtime and kept imported notes after a full process restart. The second connected the outer product: one loopback process serves UI and API, export round-trips through a separate database, and delayed browser responses cannot overwrite newer state.

The starting snapshot had 9 tests with 4 failures. The current gate passes 110 Python tests, 2 JavaScript state tests, and a separate real-Chrome acceptance flow. The important progression was from component proof to connected behavior and failure recovery: a failed export, for example, leaves the previous backup intact.

What transfers

The specific bug does not matter. These do:

• Trace backward from what a user can observe, not forward from the code you happen to be reading. The component that looks broken is often downstream of the one that is.
• Partition parallel work by connection boundary. File-level or feature-level division produces conflicts; architectural seams produce independent lanes.
• Keep one lane that only verifies, and keep it outside the implementation.
• Treat a connection as unverified until the integrated system exercises it. Passing unit tests on both sides of a boundary says nothing about the boundary.
• Re-draw the map after every integrated change. The architecture you started from is a hypothesis.

Reusable outcome: Bootwitch AGENTS

After the repair experiment, I turned the coordination method into a reusable agent skill. It creates bounded assignments, project-specific notes, append-only cross-agent messages, evidence-backed handoffs, architecture traces, and a final documentation and integration pass.

Each project touched during a session gets an updated README, architecture diagram, and technical notes based on accepted evidence. One architecture lead reviews the combined implementation, documentation, and verification before handling authorized commits, versioning, and pushes.

View Bootwitch AGENTS on GitHub · Download v0.2.0

Explore the project

The public bootwitch-doctor repository contains the repaired application, evolving architecture maps, agent packets, handoffs, test evidence, and the longer repair journey.

The deliberately broken starting state remains reproducible at 1884f4d, while the default branch remains the working repaired system.

The public repository includes the changing architecture map, implementation, and verification across process and storage boundaries.

Model Routing and Job Orchestration looks at runtime routing inside larger AI systems. This project is about a different kind of routing: dividing engineering work without losing the shared architecture.

All projects