BOROSOFTWARE All work →

Workflow retrospective · session 3b9b0869

How the way of working changed

A single multi-day agent session, 2026-07-18 to 2026-07-24, drove the port under a lead / implementer / reviewer model. The interesting story is not the code. It is how the process governing the code changed over six days, almost always in response to a concrete failure rather than up-front design. Every rule was earned, not designed.

6
days, one session (with periodic compaction)
9
dated governance changes after the initial import
126
agents · 19,423 assistant turns
~$2,771
computed cost estimate (not a billed figure)
The shape of it PM.md and Rust.md were imported once on day one and never edited again — the constitution. Every subsequent change, all nine of them, landed in CLAUDE.md, the single living process document — the case law. The generic docs stayed frozen; the project-specific one absorbed all the learning.

Timeline

Dates, times, and commit hashes are deterministically extracted from the session's own git history. Red nodes mark the three inflection points.

Cost & token economics

Token counts were aggregated deterministically from the main transcript and all 125 subagent transcripts. Dollar figures apply published first-party per-model rates, with cache-read at 0.1× input and cache-write at 2× input (1-hour TTL). No cost field is recorded in the transcripts, so every dollar amount here is a computed estimate, not a billed total.

Spend by model

Opus is the plurality for a structural reason: it ran the lead/orchestration loop for the full six days plus every correctness-critical review — both context-heavy, which shows up as cache traffic.

Bars share one hue on purpose — length is the only variable that carries meaning here.
Show data table
ModelSpend% of totalAgentsRole
Opus 4.8$1,49254%60 (+ main loop)Lead / orchestration; correctness-critical reviews
Sonnet 5$73827%46Primary implementer tier
Fable 5$53919%17One-tier-up reviewer for Opus-authored work
Haiku 4.5$2.46~0%2Mechanical / doc tasks
Total$2,771100%126

Where the money actually went

Cache traffic, not generation, is the cost driver. Re-reading and re-priming context per turn is 91% of spend; the prose the models actually wrote is 9%. That split is the signature of long-context agentic work — a 10.1M-token output total is dwarfed by 3.46 billion cache-read tokens.

Segments are labelled in place and keyed below, so the split reads without relying on colour.

The tiering policy is visibly working

Sonnet implementers out-produced Opus in raw output tokens, at roughly 40% lower per-token cost. "Cheapest tier that fits the work" is doing real work, not just nominally in effect.

Raw generation output, implementer tiers. Fable's 17 reviews and Haiku's 2 tasks are excluded here.
One reading worth surfacing Haiku's near-zero footprint — $2.46 across 2 agents — suggests the mechanical/doc tier was barely used this cycle. A possible signal that more tickets could have been sliced down to haiku-sized work.

The change that mattered most: mutation-probing

Green test suites kept proving hollow. Three failure modes converged on 2026-07-21: 70 green tests behind four unpinned load-bearing behaviors (FDR-53); an inert error-path test whose entire body could be replaced with return while 484 tests still passed (FDR-55); and two self-referential constant assertions that "pass" even when the constant changes. Each satisfied "tests exist" while proving nothing.

The rule that landed (7eceda3): for any ticket touching protocol logic, state machines, timing, or a driver data path, the reviewer copies the crate to a scratchpad, deliberately breaks each behavior the tests claim to cover, and reports which mutations survive. A surviving mutation is the finding. Green tests are not evidence; only a test that goes red when the behavior is deleted counts as coverage.

113
mutations applied across FDR-49 and FDR-50
7
confirmed survivors fixed before merge
1
design-level aggregation trap (the OR-vs-sum bug) caught
1
process hazard surfaced by honest self-disclosure

The single most valuable catch was a trap a fixture hid: multi-ECU readiness is an OR over a shared bitmask, not a per-ECU sum, but the one shipped fixture's ECUs have disjoint monitor sets, so a naive sum produces the identical number and passes every test. It would have shipped wrong on any vehicle whose ECUs share a monitor — caught only because a pre-implementation pass demanded an overlapping-bit test no fixture provided.

Full narrative in the whitepaper, §7.