Dependency and security upgrade sweeps
Ordered batches with a reviewer, not one hopeful auto-fix
Work through a dependency backlog in ordered, reviewable batches: what depends on what, what has to move together, what the upgrade breaks, and what the run could not prove.
What actually goes wrong today
Stated plainly, because the approach below only makes sense as an answer to something specific.
- 01
A version bump looks mechanical right up to the point where something breaks — and the break is usually in code that relied on behaviour nobody documented.
- 02
Auto-fixers are good at the mechanical half and blind to the half that matters. They also give you one enormous diff, which is the least reviewable artifact in software.
- 03
The employee doing the upgrade is rarely the one who knows which module depends on the old behaviour, and that knowledge is not written down anywhere they can read.
- 04
A sweep has an ordering problem: some upgrades must move together, and doing them in the wrong order produces failures that look like the upgrade was wrong when it was merely early.
How the hierarchy and the router do it
Concretely, stage by stage: which mode the stage uses, who owns it, and why the router prices it the way it does.
- 01
Research establishes what the codebase actually uses: imports, lockfile entries, call sites, and which packages move as a set. Reading, not guessing.
- 02
A debate settles the upgrade order, then the chair records it — the sequencing decision is the one that gets silently dropped when a single agent does the work.
- 03
The CTO writes the batch plan as files, so "upgrade these four together, then these two" is explicit rather than implied by the order the agent happened to work in.
- 04
Developer agents apply each batch with edit_file and write_file; run_shell goes through a human approval round trip, so the one tool that can execute anything is also the one that stops and asks.
- 05
QA tries to falsify the result against the built code in the workspace. A failed review sends the work back to the employees who wrote the files, not to a fresh agent that has to rediscover the problem.
What you actually end up with
Artifacts, not assurances. Every one of these is something you can open, diff, review or throw away.
Batches that can be reviewed and reverted one at a time, instead of one diff nobody can hold in their head.
A written upgrade order with the dependency reasoning attached, which is the artifact that makes the next sweep cheaper.
The honest failure mode as output: what the run could not verify, stated as unverified rather than implied to be fine.
Which part of the company is involved
Six of the thirteen roles, four of the eight departments. The rest of the office stays idle, and that is what keeps the run affordable.
Sizes the sweep and decides how many batches it deserves.
Establish what the code actually uses: imports, call sites, lockfile entries, and which packages must move as a set.
The upgrade order is the decision that gets silently dropped when one agent does the work.
Writes the batches as files: upgrade these four together, then these two — explicit rather than implied by work order.
edit_file and write_file per batch. run_shell is the one tool that stops for a human approval round trip.
Tries to falsify against the built code in the workspace and sends objections back to the employees who wrote the files.
Modes used
Intake runs single, research runs parallel, contested decisions run as a debate, and anything that produces files ends in a review-loop.
Where the money goes
Reading and summarising sit on cheap bands. The plan, the implementation turns and the review escalate, because those are the turns where being wrong is the expensive mistake.
What is recorded
Per-turn cost, the route decision and the models the router rejected, the files touched, and the debate ruling including the position that lost.
Two other jobs in the same shape
Backfilling tests on untested code
Tests that fail when the behaviour breaks, not when it is refactored
Find the behaviour boundaries in code that has never been exercised, write tests against them, and have the run prove that each test actually detects a change.
Read itCutting model cost on routine work
Pay frontier prices for the decisions, not for the summaries
Move the routine turns of an agent workflow onto the cheapest models that can do them, and keep the expensive ones where being wrong is expensive — with a recorded reason for every route decision.
Read itRun this in mock mode first
Node 24, one install, no API keys. The pipeline, the stages, the file writes and the review loop all run against scripted employees, so you can watch the shape of the work before it costs anything.
Nothing in the orchestrator authenticates, so bind it to localhost. The tools are confined to the run workspace, but that workspace is a normal directory on the machine and the orchestrator is not inside an operating-system sandbox — give it a checkout you would be willing to lose.