Lining up an unattended overnight run, two of the units were risky to do without me watching. The reflex was binary. The right move was not.
I was setting up an autonomous run, the kind that executes while I am asleep and cannot answer a question. Most of the queue was safe to run alone. Two units were not. One was greenfield architecture, the kind of open-ended design work that drifts without a human at the forks. The other wrote into a live, deployed service, which is exactly the irreversible-in-production category you do not want an unsupervised agent touching.
The reflex when a unit is risky to automate is binary. Either you run it autonomous and accept the risk, or you hold it for a supervised session and lose the autonomy. Two boxes. Pick one.
i.The hidden third box
There is a third move, and it is usually better than either: descope. Do not ask run it or hold it. Ask what specifically makes this risky, and can I cut that piece while keeping the value.
For the unit that wrote into the live service, I looked at why the write was there. It turned out the write was not even needed. The surface the run was feeding already accepted the input through another path; the live-service write was a redundant belt on top of an existing suspender. So I cut it. Stripped the one piece that touched the deployed service out of the unit, and the unit kept all the value it actually had, minus a write it never needed.
And then something fell out for free. That risky write was the only reason the run required a sensitive permission grant. Cut the write, and the permission requirement vanished with it. The descope did not just lower the risk of one unit. It removed an entire capability the autonomous run would otherwise have had to be trusted with.
On scope The risky permissiondropped out with thepiece that needed it.That is the descopedoing double work.
ii.Why the binary framing traps you
Run-it-or-hold-it feels like the whole choice because it treats the unit as atomic, an indivisible lump that is either safe or not. Most units are not atomic. They are bundles, and the risk usually lives in one or two strands of the bundle, not the whole thing. When you treat the unit as a lump, you let the riskiest strand decide the fate of all the safe strands tied to it.
Hold the whole unit because one piece is dangerous, and you have paused a pile of safe work to protect against a small risk. Run the whole unit to avoid the delay, and you have accepted the dangerous piece to ship the safe ones. Both are bad trades, and both come from refusing to take the unit apart.
iii.Find the cut that removes the risk
The descope move is to look for the cut that removes the risk while keeping the value. Sometimes the risky piece is essential and there is no cut, in which case you are back to run-or-hold and you choose deliberately. But often the risky piece is not load-bearing. It is a nice-to-have, a redundancy, a bit of scope that crept in, and removing it costs you almost nothing while removing the entire reason the unit could not run alone.
That was the case here. The live-service write was scope that had crept in, not value the run depended on. Cutting it turned an unsafe-to-automate unit into a safe one, kept everything that mattered, and shrank the permission surface of the whole run. One cut, three wins.
iv.Descope is a first-class option
The habit worth building is to add descope as a standing third option any time a piece of work is too risky to automate. Do not let the choice collapse to run-or-hold. Take the unit apart, find the strand carrying the risk, and ask whether that strand is essential or just present. If it is just present, cut it, and watch how much risk leaves with it.
The best version of this is what happened here: the cut not only de-risked the unit, it deleted a dangerous capability from the whole run. That is descope earning its place at the table. It is not a compromise between doing and not-doing. It is often the move that gets you more value at less risk than either of the two you were choosing between.
Drafted with Bishop, my AI partner.
Words picked, edited, and approved by me.
Model provenance: Claude Code (Claude Opus and Sonnet)