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.

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

README · ARCHITECTURE · TECHNICAL

Starting conditions

Field Notes, the application being repaired, was generated for this exercise. I specified a late-prototype workspace carrying known, deliberately introduced defects, and ChatGPT produced the codebase. It is committed under a neutral Chaos Lab handoff identity so that the repair began the way inheriting an unfamiliar codebase does: no author to ask, no design rationale, only the code and a README describing what it was supposed to do.

Generating the substrate is what made the result measurable. Because the defects were introduced on purpose, recovery could be checked rather than asserted. A repair of someone else's genuinely broken code would have been a better story and a worse experiment — there would have been no ground truth to compare against.

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

1. Draw the architecture as it existed, not as the documentation said it should exist.
2. Trace observable outcomes backward to the state owner.
3. Mark broken or missing connections red.
4. Fix the furthest red connection first.
5. Give every agent a distinct boundary and a standard handoff.
6. Re-run the forward and backward traces after every integrated change.
7. Verify from outside the implementation.

Step 5 is what made parallel work survivable. Agents editing one repository usually collide. Dividing the work by connection boundary rather than by file or feature meant each agent's edits barely intersected with the others, and the places they did intersect were known in advance and owned by the integration lane.

The five lanes

• Architecture and integration: contracts, dependency order, trace updates, and integration checks.
• Durable storage: the SQLite adapter, schema handling, transactions, and close/reopen persistence.
• Atomic import: whole-payload validation and all-or-nothing publication.
• Runtime composition: selecting one repository, wiring the server, and moving the CLI to one batch request.
• Independent verification: HTTP requests, the real CLI, controlled failure, and restart tests — written against observable behavior, by a lane that did not implement any of it.

The verification lane mattered most. An agent that implements a component and then tests it will write tests shaped like the implementation. Keeping that lane separate is the same reason the person who runs an assay should not be the one who scores it.

The integration role mattered nearly as much. It caught issues that were locally reasonable but wrong for the connected system, including startup side effects, overly broad error classification, and a missing batch-concurrency regression.

Before, during, and after

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 architecture page follows the changing system and agent boundaries. Technical explains the implementation and why the verification crosses 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