Fiscal year-end batch, two days to under four hours
The year-end close re-architected with parallel processing, so a run that took more than two days finishes in under four hours and can be restarted where it stopped.
The constraint
The fiscal year-end close ran as one long serial batch, more than two days end to end, inside a window that couldn't move. If a step failed late on the second day, the run started over. Everyone who depended on the close, from accounting to the people answering member calls, waited on it.
The decision
Break the run into units that don't depend on each other and run them side by side. That meant finding every hidden dependency first, which is where the real work was. Each step became restartable, so a failure resumes from the last good point instead of from the beginning. The results of the new run were reconciled against the old one before anybody trusted it.
What it cost
The dependency hunt. Years of batch code carry assumptions about order that nobody wrote down, and each one has to be found and either removed or made explicit. Then a parallel run of old and new, line by line, to prove the numbers matched.
What shipped
A close that finishes in under four hours. A failed step is rerun on its own.
What it showed
The speed came from removing shared state, not from faster hardware. Audit-grade work can be fast when each step is idempotent and leaves a record. That's the same discipline I want from an agent pipeline: every step replayable, every result reconciled.